DevOps change request attributes

Release version: Washingtondc

Updated November 11, 2024

4 minutes to read

Summarize

Summarized using AI

Summary of DevOps Change Request Attributes

This guide details how to add or update DevOps change request attributes using various methods, including the changeInfo REST API, Default Change Handler subflow, and orchestration pipeline functions. Understanding these options enables ServiceNow customers to manage change requests effectively and streamline their DevOps processes.

Show full answer Show less

Key Features

REST API: Use the DevOps - PUT /devops/orchestration/changeInfo/{changeInfo} to update specific change request fields. Note that this API cannot be executed when the pipeline is paused.
Default Change Handler Subflow: Automatically populates change request fields with default values.
Orchestration Pipeline: Pass change attributes through the pipeline or use the Update function for managing change details in Azure DevOps and Jenkins.
Automated Flows: Implement DevOps approval flows to modify change requests efficiently.

Key Considerations

When specifying change attributes through multiple methods, the order in which values are considered varies:

Attributes can be set in the pipeline step, Default Change Handler subflow, or approval flow.
Conflicts may arise if attribute values are set in both the Default Change Handler subflow and approval flows simultaneously; it is crucial to use only one source for setting attributes.

Practical Scenarios

Scenario 1: If the assignmentgroup is "change mgmt" in the Default Change Handler and "CAB" in the Update function, "change mgmt" is considered initially, and "CAB" after approval.
Scenario 2: If "change mgmt" is set in the Default Change Handler and "chg mgmt1" in the pipeline step, "chg mgmt1" will be used during creation.
Scenario 3: If the templates specify "change mgmt" and "chg mgmt1", the value from the change attribute template will take precedence.
Scenario 4: For model-based changes, the model preset value will be considered over the change attributes if specified.

Customers must also ensure the sndevops.changerequest.applyattributesoncreation property is set to true if business rules are used, to apply attributes at creation rather than after.

Add or update DevOps change request attributes using the changeInfo REST API, the Default Change Handler subflow, by passing attributes through the pipeline, Update function, or automated flows.

Specifying attributes

Use one of the following methods to specify change request attributes:

DevOps - PUT /devops/orchestration/changeInfo/{changeInfo} to update fields within a specified change request.
Note:
- The changeInfo API won’t function when the pipeline is in the paused state.
- An API call can’t be executed while the pipeline is waiting.
- The API approach must be considered after thorough testing.
Default Change Handler subflow to populate change request fields with default values. For more information, see Default Change Handler subflow.
Passing the change attributes through the orchestration pipeline. For more information, see Configuring DevOps change request details within the pipeline.
Passing the change attributes through the Update function in the orchestration pipeline function. For more information, see the following:
Automated flows: DevOps approval flows to make changes in a change request. For more information, see Flows.

Precedence of consideration

When the change attributes are specified through multiple methods, the precedence in which the attribute values are considered will vary. In ServiceNow, attributes can be specified in the pipeline step of DevOps Change Velocity, in the Default Change Handler subflow, or in an approval flow. In the orchestration tool pipeline, attributes can be passed in the pipeline step, or using the REST APIs. If a change model is used, they can also be specified in model presets.

See the following tables and examples to understand the precedence in which the values will be considered.

Table 1. Precedence of change attributes for type-based changes
Change request	Precedence
Standard	Change attributes passed through pipeline Step record fields in ServiceNow Template passed in change attributes through pipeline Template in Step fields in ServiceNow
Non-standard	Change attributes passed through pipeline Default Change Handler subflow & approval flows Important: Setting attribute values in both the Default Change Handler subflow and approval flows can cause conflicts because they might run simultaneously. Set the attribute values in only one source to avoid issues. Step record fields in ServiceNow Template passed in change attributes through pipeline Template in Step fields in ServiceNow

Table 2. Precedence of change attributes for model-based changes
Change request	Precedence
Standard	Model Presets Change attributes passed through pipeline Step record fields in ServiceNow Template passed in change attributes through pipeline Template in Step fields in ServiceNow
Non-standard	Model Presets Change attributes passed through pipeline Default Change Handler subflow & approval flows Important: Setting attribute values in both the Default Change Handler subflow and approval flows can cause conflicts because they might run simultaneously. Set the attribute values in only one source to avoid issues. Step record fields in ServiceNow Template passed in change attributes through pipeline Template in Step fields in ServiceNow

Note:

If you have used business rules in your change operations, then you must set the sn_devops.change_request.apply_attributes_on_creation property to true, so that the change attributes passed in the pipeline are set when the change request is created instead of the attributes being passed after the change request is created. For more information, see DevOps Change Velocity properties.

Scenario 1

Consider a scenario where the attributes are specified in the Default change handler subflow in ServiceNow and in the Update function in the orchestration pipeline. Assume that the assignment_group attribute is specified as “change mgmt” in the Default change handler subflow, and as “CAB” in the Update function in the pipeline. In this scenario, when the change is created, the value from the Default change handler subflow will be considered, and “change mgmt” will be the value considered for assignment_group. Once the change is approved, and the pipeline is resumed, the value specified in the Update function will be considered, i.e. “CAB”.

Scenario 2

Consider a scenario where the attributes are specified in the Default change handler subflow in ServiceNow and in the change step in the orchestration pipeline. Assume that the assignment_group attribute is specified as “change mgmt” in the Default change handler subflow, and as “chg mgmt1” in the change step of the pipeline. In this scenario, when the change is created, the value from change step (chg mgmt1) will be considered, and then once the Default change handler subflow is triggered, the value considered will be “change mgmt”.

Scenario 3

Consider a scenario where the attributes are specified through the template passed in change attributes and in the template of the step record. Assume that the assignment_group attribute is specified as “change mgmt” in the template passed in change attributes, and as “chg mgmt1” in the template of the pipeline step record. In this scenario, when the change is created, the value from the template passed in change attribute (chg mgmt) will be considered.

Scenario 4

Consider a scenario where the attributes are specified in the change attributes and the model preset for a model-based change. Assume that the assignment_group attribute is specified as “change mgmt” in change attributes and as “chg mgmt1” in the model preset. In this scenario, when the change is created, the value from model preset (chg mgmt1) will be considered.