What are key relationships between Changes and Incidents? Choose 2 answers

The relationship between Incident and Change Management is a core concept in ITSM. A change, especially if it fails or has unintended consequences, can directly cause an incident (e.g., a server patch causes an application to stop working). This is represented by the "Caused by Change" relationship. Conversely, to resolve an incident that requires a modification to a Configuration Item (CI), a formal change request must be raised. This ensures the fix is planned, approved, and documented, thereby resolving the incident and its underlying cause. This is often initiated via the "Create Change" action on an incident record.

A. An incident owner's role does not inherently place them in the change approval workflow; approvals are typically managed by change approvers or the CAB.

D. This is not out-of-the-box functionality. An incident requires its own closure process, including user confirmation, and does not automatically close with a related change.

1. ServiceNow Product Documentation: "Create a change request from an incident." This document explicitly states

"You can create a change request from an incident to resolve the incident." This directly supports option C.

2. ServiceNow Product Documentation: "Relate an incident to a change request." This document details the "Caused by Change" field on the Incident form

which is used to link an incident that was a result of a change implementation. This directly supports option B.

3. ServiceNow Product Documentation: "Incident Management state model." The documentation on the incident lifecycle shows that moving to a 'Closed' state requires specific conditions or manual action after resolution. It does not mention automatic closure based on a related change

which invalidates option D.

4. ServiceNow Product Documentation: "Change Management approvals." The documentation outlines that approvals are configured based on user roles

groups (like the Change Advisory Board)

and specific individuals

not automatically based on the "owner" of a related incident. This invalidates option A.