DevOps change request attributes

Release version: Yokohama

Updated July 31, 2025

4 minutes to read

Summarize

Summarized using AI

Summary of DevOps change request attributes

This content explains how ServiceNow customers can add or update DevOps change request attributes by using several methods, including the changeInfo REST API, the Default Change Handler subflow, pipeline configurations, Update functions, and automated approval flows. It is designed to guide customers in efficiently managing change request fields within DevOps orchestration pipelines and change models.

Show full answer Show less

Specifying Change Request Attributes

REST API: Use the DevOps PUT /devops/orchestration/changeInfo/{changeInfo} API to update fields in a specific change request. Note that the API cannot be used while the pipeline is paused, so thorough testing is recommended before implementation.
Default Change Handler subflow: Automatically populates change request fields with default values during processing.
Pipeline configuration: Pass change request attributes directly through orchestration pipeline steps or via the Update function within the pipeline.
Custom actions: Implement custom pipeline actions using Docker container images or ServiceNow DevOps custom actions from GitHub Marketplace.
Automated approval flows: Use DevOps approval flows to make approved changes in change requests automatically.

Precedence of Attribute Values

When multiple methods specify the same change request attributes, the system follows a defined precedence order to determine which values are applied:

Type-based changes:
- Standard changes: Attributes specified in the pipeline step take precedence, followed by ServiceNow step record fields, then templates passed in change attributes, and finally template fields in ServiceNow.
- Non-standard changes: Attributes passed through the pipeline have highest precedence, followed by values from the Default Change Handler subflow and approval flows (note potential conflicts if both are set simultaneously), then ServiceNow step record fields, and templates.
Model-based changes:
- Standard changes: Model presets have the highest precedence, followed by pipeline-passed attributes, then step record fields and templates.
- Non-standard changes: Model presets lead, then pipeline attributes, followed by Default Change Handler subflow and approval flows (again, avoid setting both simultaneously), and finally step record fields and templates.

Important: Avoid setting attribute values in both the Default Change Handler subflow and approval flows simultaneously to prevent conflicts, as these may run at the same time.

Additional Configuration

If business rules affect change operations, set the sndevops.changerequest.applyattributesoncreation property to true to ensure attributes passed in the pipeline are applied at creation rather than afterward.

Practical Scenarios

Scenario 1: When attributes differ between the Default Change Handler subflow and the Update function in the pipeline, the subflow’s values apply at creation, and the Update function’s values apply after approval when the pipeline resumes.
Scenario 2: When attributes differ between the Default Change Handler subflow and the orchestration pipeline change step, the pipeline step values apply at creation, and the subflow values apply afterward.
Scenario 3: When attributes differ between templates passed in change attributes and templates in step records, the template passed in change attributes takes precedence at creation.
Scenario 4: For model-based changes, if attributes differ between change attributes and model presets, the model preset values take precedence at creation.

What Customers Can Expect

By understanding and applying these methods and precedence rules, ServiceNow customers can reliably control and automate the assignment and updating of change request attributes within DevOps pipelines. This enables more consistent change management, reduces manual intervention, and integrates smoothly with various orchestration tools and approval mechanisms.

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.