DevOps change request attributes

  • Release version: Xanadu
  • Updated July 31, 2025
  • 4 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of DevOps Change Request Attributes

    This content explains how ServiceNow customers can add or update DevOps change request attributes using various methods such as the changeInfo REST API, Default Change Handler subflow, orchestration pipeline, Update function, or automated flows. It highlights the practical ways to specify, manage, and control the precedence of change request attributes to ensure accurate and consistent change management within DevOps pipelines.

    Show full answer Show less

    Specifying Change Request Attributes

    • changeInfo REST API: Use the DevOps PUT API to update fields within a specified change request. Note that this API does not function when the pipeline is paused, so thorough testing is recommended before implementation.
    • Default Change Handler subflow: Automatically populates change request fields with default values within ServiceNow.
    • Orchestration pipeline: Pass change attributes directly through the pipeline steps or via the Update function in orchestration pipelines for Azure DevOps, Jenkins, or custom actions using Docker container images.
    • Automated flows: Use DevOps approval flows to make controlled changes to change requests.

    Precedence and Conflict Management

    Attributes can be specified in multiple locations, and their precedence determines which value is ultimately applied. The precedence varies between type-based and model-based changes and depends on where the attributes are set:

    • Type-based changes:
      • Standard changes prioritize attributes passed through the pipeline, followed by step record fields, then templates passed in change attributes, and finally templates in step fields.
      • Non-standard changes consider pipeline attributes first, then Default Change Handler subflow and approval flows, followed by step record fields and templates.
    • Model-based changes:
      • Standard changes prioritize model presets, pipeline attributes, step record fields, then templates.
      • Non-standard changes prioritize model presets, pipeline attributes, Default Change Handler and approval flows, then step record fields and templates.

    Important: Setting attribute values both in the Default Change Handler subflow and approval flows simultaneously can cause conflicts because they might run concurrently. Customers should configure attributes in only one of these sources to avoid issues.

    Additional Configuration Note

    If business rules are used in change operations, set the sndevops.changerequest.applyattributesoncreation property to true. This ensures that attributes passed in the pipeline are applied when the change request is created rather than afterward.

    Practical Scenarios Demonstrating Precedence

    • Scenario 1: When assignmentgroup is set in both the Default Change Handler subflow and Update function, the Default Change Handler value applies at creation, and the Update function value applies after approval.
    • Scenario 2: When assignmentgroup is set in the Default Change Handler and orchestration pipeline change step, the pipeline step value applies at creation, followed by the Default Change Handler value upon trigger.
    • Scenario 3: When assignmentgroup is specified in both the template passed in change attributes and the pipeline step template, the template passed in change attributes takes precedence at creation.
    • Scenario 4: For model-based changes, when assignmentgroup is set in both change attributes and model presets, the model preset value applies at creation.

    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:

    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
    1. Change attributes passed through pipeline
    2. Step record fields in ServiceNow
    3. Template passed in change attributes through pipeline
    4. Template in Step fields in ServiceNow
    Non-standard
    1. Change attributes passed through pipeline
    2. 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.
    3. Step record fields in ServiceNow
    4. Template passed in change attributes through pipeline
    5. Template in Step fields in ServiceNow
    Table 2. Precedence of change attributes for model-based changes
    Change request Precedence
    Standard
    1. Model Presets
    2. Change attributes passed through pipeline
    3. Step record fields in ServiceNow
    4. Template passed in change attributes through pipeline
    5. Template in Step fields in ServiceNow
    Non-standard
    1. Model Presets
    2. Change attributes passed through pipeline
    3. 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.
    4. Step record fields in ServiceNow
    5. Template passed in change attributes through pipeline
    6. 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.