DevOps change request attributes

  • Release version: Zurich
  • Updated March 12, 2026
  • 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

    ServiceNow enables customers to add or update DevOps change request attributes using multiple methods within the Release Zurich platform. Change request attributes can be specified and managed via the changeInfo REST API, orchestration pipeline steps, the Default Change Handler subflow, Update functions, and automated flows. Understanding how to set and prioritize these attributes is critical for effective change management in DevOps pipelines.

    Show full answer Show less

    Methods to Specify Change Request Attributes

    • changeInfo REST API: Use the PUT /devops/orchestration/changeInfo/{changeInfo} endpoint to update fields within a specific change request. Note that this API does not work if the pipeline is paused or waiting; thorough testing is recommended before implementation.
    • Default Change Handler subflow: Automatically populates change request fields with default values during orchestration.
    • Passing attributes through the orchestration pipeline: Attributes can be passed directly in pipeline steps.
    • Update function in orchestration pipelines: Used to get and update change request details within Azure DevOps or Jenkins pipelines.
    • ServiceNow DevOps custom actions: Custom actions can be implemented in pipelines using generic Docker container images.
    • Automated flows: Approval flows can be configured to make changes in change requests automatically.

    Precedence of Change Request Attributes

    When attributes are specified by multiple methods, attribute values are applied based on a defined precedence, which varies depending on whether the change is type-based or model-based, and whether it is standard or non-standard.

    Type-based Changes

    • Standard change requests: Priority is given to attributes passed through the pipeline step, followed by ServiceNow step record fields, template passed through pipeline, and template in step fields.
    • Non-standard change requests: Attributes from the pipeline take precedence, followed by the Default Change Handler subflow and approval flows, then ServiceNow step record fields, and template attributes.

    Model-based Changes

    • Standard model-based changes: Model presets have the highest precedence, followed by pipeline step attributes, ServiceNow step record fields, and templates.
    • Non-standard model-based changes: Precedence is model presets, pipeline step attributes, Default Change Handler subflow and approval flows, ServiceNow step record fields, then templates.

    Important: Avoid setting attribute values simultaneously in both the Default Change Handler subflow and approval flows to prevent conflicts, as they may run concurrently. Set attributes in only one of these sources.

    Additional Configuration Note

    If business rules are used for change operations, set the sndevops.changerequest.applyattributesoncreation property to true to ensure that attributes passed in the pipeline are applied at change request creation rather than after creation.

    Practical Scenarios

    • Scenario 1: Attributes specified in Default Change Handler subflow and Update function—initial attribute values from the Default Change Handler subflow are used when creating the change, while Update function values apply after approval when the pipeline resumes.
    • Scenario 2: Attributes set in Default Change Handler subflow and orchestration pipeline change step—initial values come from the pipeline change step; later, the Default Change Handler subflow overrides them.
    • Scenario 3: Attributes specified via template passed in change attributes and template in pipeline step record—the value from the template passed in change attributes is used at creation.
    • Scenario 4: Attributes specified in change attributes and model preset for model-based changes—the model preset values take precedence when the change is created.

    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.