---
title: "When are Change Requests, CAPAs, Anomalies, and Complaints included in the Change Management File"
description: "Change Requests, CAPAs, Anomalies, and Complaints are included in the Change Management File (CMF) only when they affect or are related to any items that change within the current release. If they are not affected or are not related to any item change, then they won’t be included."
category: "Frequently Asked Questions"
section: "Ketryx Lifecycle Management"
keywords: ["complaints", "capas", "management file", "change requests", "change management", "anomalies", "included", "related change"]
source_url: "https://support.ketryx.com/hc/en-us/articles/38204865124493-When-are-Change-Requests-CAPAs-Anomalies-and-Complaints-included-in-the-Change-Management-File"
last_reviewed: 2026-06-11
---

# When are Change Requests, CAPAs, Anomalies, and Complaints included in the Change Management File

> **In short:** Change Requests, CAPAs, Anomalies, and Complaints are included in the Change Management File (CMF) only when they affect or are related to any items that change within the current release. If they are not affected or are not related to any item change, then they won’t be included.

Change Requests, CAPAs, Anomalies, and Complaints are included in the Change Management File (CMF) only when they affect or are related to any items that change within the current release. If they are not affected or are not related to any item change, then they won’t be included.

For point-wise items like Change Requests and CAPAs, this means they appear only in the version specified in their "Introduced in Version" field. In contrast, long-lived items like Anomalies and Complaints span multiple versions: they appear in every CMF from their "Introduced in Version" until (but not including) their "Obsolete in Version." For example, an Anomaly introduced in 1.0.0 will be included in the CMF for all subsequent versions it remains active in, and may be pulled into a later release (e.g., 1.0.2) if newly linked items are impacted. Record locking can override this logic, and the type of release (full, patch, or scoped) can also influence inclusion. This behavior is defined in the [Ketryx Lifecycle Management Manual (MAN-01)](https://chatgpt.com/c/6877ea0b-c3a8-8005-a3fa-face3e0e16eb).

## Related articles

- [What are long-lived and point-wise (short-lived) configuration items? What are the differences between the two?](what-are-long-lived-and-point-wise-short-lived-configuration-items-what-are-the.md)
- [Is the release version in Jira the same as the one in Ketryx?](is-the-release-version-in-jira-the-same-as-the-one-in-ketryx.md)
- [How does Ketryx enable users to work on multiple versions and deployments for the same project?](how-does-ketryx-enable-users-to-work-on-multiple-versions-and-deployments-for.md)
- [What are the Ketryx default release documents and what are the documents omitted by default? How do I re-include them in my release?](what-are-the-ketryx-default-release-documents-and-what-are-the-documents.md)
- [What appears in the \"Identification of characteristics related to safety\" section of the Risk Management File?](what-appears-in-the-identification-of-characteristics-related-to-safety-section.md)