Enable the change acceleration feature of DevOps Change Velocity for automatic change request creation in your pipeline, and use change approval flows and policies to automate approval under certain conditions.

Note: ServiceNow Change Management must be installed for change acceleration.
Enable and set up change control when you model your pipeline in DevOps:

You can view details for active change requests by navigating to DevOps > Orchestrate > Pipeline Change Requests.

Change control process

When change control is enabled for a job in your DevOps development pipeline, a change request is automatically created and set to Assess state to request approval for the execution of the current stage or job if an assignment group is added for the change request. Change requests can be approved automatically by configuring conditions in a change approval policy.

Pipeline steps can be configured to enable change receipts, which do not pause the pipeline. Change requests created with change receipts enabled include all pipeline data, but do not require approval to proceed in the pipeline and the change request will be in post implement states. For change requests created without enabling change receipt, the pipeline will be paused until the change request is approved, and upon approval, the pipeline will be resumed.

If you want to stop the automatic transition of the change request states even when change receipt is turned on, you must disable the sn_devops.enable_change_receipt_state_transition property. For more information, see DevOps Change Velocity properties.

Once approved, either automatically or manually, change requests move to Implement state and the job is run. Once the job is run, the change request is moved to the closed state with Close code as successful on a successful job run or Unsuccessful on error in the job run. For information on customizing your change request states, see Custom change request process.

If a change request is not approved and moved to the canceled or closed state, the associated Jenkins, GitHub, or ADO job is marked as failed and a console message is shown:

For Jenkins: [ServiceNow DevOps] Job was not approved for execution

For GitHub: Error: **** Change has been created but the change is either rejected or cancelled

For ADO: "changeState":"Closed"

Automatic approval of change requests using flows and policies

You can automate the change approval process for all your DevOps change requests. DevOps Change Velocity uses flows and DevOps data (such as work items, commits, code coverage, code security, risk, and test results) to update the state of a change request and automatically approve it based on change approval policies. Three flows are available in the base system that you can clone, customize, and activate (in Flow Designer). By default, the DevOps Change Request Manual Approval Flow is activated. DevOps flows are applicable to only automatically created change requests or change requests that have change receipt turned off.

Flows

A flow is an automated process consisting of a trigger (which specifies when to run the flow) and a sequence of reusable actions (where the actions perform a sequence of operations on your data). Flows are built in Flow Designer, a ServiceNow AI Platform feature that enables process automation. For more information, see Flow Designer.

You can use one of the DevOps flows available in the base system as a template; clone the flow and customize it to your business requirements. Ensure that only one DevOps flow is in the active state at any time to avoid conflicts and errors. A DevOps flow is applicable to change requests that have the DevOps category or if the devops_change property is set to true. (An automatically created DevOps change request sets the category to DevOps by default).

By default, the flows are configured to update the state of the step execution based on the change request state, and any additional default behavior. Based on the step execution state, a callback is made to the pipeline:
  • If the DevOps change request is approved, the flow will update the step execution state to approved, and the change request state is updated to implement. After that the pipeline will be resumed.
  • If the DevOps change request is rejected, the flow will update the step execution state to rejected, and the change request state is updated to new. After that the pipeline will be terminated.
  • If the DevOps change request is canceled, the flow will update the step execution state to canceled by user, and the change request is updated to canceled. After that the pipeline will be canceled.

If a business rule or data policy causes an error while updating a change in the DevOps Change Request Manual Approval Flow, DevOps Change Request Minimal Automation Approval Flow, or DevOps Change Request Advanced Automation Approval Flow, the corresponding error will be displayed in the worknotes of the change request and logged in the console logs of the pipeline tool.

To read guidelines on how to use flows, subflows, and actions more effectively, see General guidelines for Workflow Studio flows, subflows, and actions.

Change approval policies

A change approval policy is a course of action that can be applied to a change request. It consists of the following:
  • Policy input: Variable sources evaluated within a condition.
  • Decisions: Determines whether the change approval definition must be applied based on conditions.
  • Approval definitions: Defines the type of approval that can be applied.
The DevOps Change Request Minimal Automation Policy and DevOps Change Request Advanced Automation Policy are available by default. The three normal change policies available are:
  • DevOps Model Change Policy
  • DevOps Change Request Minimal Automation Policy
  • DevOps Change Request Advanced Automation Policy

For more information on change approval policies, see Change approval policies.

The DevOps automated approval flows use change approval policies and DevOps data (such as work items, commits, pull requests, test summaries, security summaries, and quality summaries) to automatically update the change record state and step execution state to approved, rejected, or canceled. You can view and edit these policies based on your business requirements, or create your own in the decision table. See the following decision tables.

The DevOps Change Request Minimal Automation Policy has the following conditions and criteria by default: Change Request Minimal Automation Policy conditions

The DevOps Change Request Advanced Automation Policy has the following conditions and criteria by default:Change Request Advanced Automation Policy conditions

The three outcomes for the DevOps Change Request Minimal Automation and DevOps Change Request Advanced Automation policies (depending on the conditions that you specify) are:
  • Auto approval: If the conditions specified in the policy are met, the change request is automatically approved.
  • Auto reject: If one or more of the conditions specified in the policy are not met, the change request is automatically rejected.
  • Manual approval: If one or more conditions need manual approval by a user or group, that is specified in the policy. Notifications are sent by the policy to the relevant users or groups to expedite the manual approval and progress the change request.

You can apply your change approval policy in the Change Management Workflow Studio action to control the approval process for a change request. For more information, Use the Apply Change Approval Policy flow action.

Change approval work notes

When a change request is updated based on a flow and change approval policy, the work notes associated with the change request are updated to one of the following hard-coded messages:

  • Change Approval Policy not found. Change Request has been rejected (%s).
  • %s is inactive. Change Request has been rejected (%s).
  • No Decisions matched. %s has been skipped (%s).
  • No approvals were generated from matched Decisions. %s has been skipped (%s).
  • Change Request has been rejected by %s (%s).
  • Change Request has been approved by %s (%s).
The work notes are updated based on a logic which uses the combination of one of the hard-coded messages + the policy name + action label used in the flow associated with the change request. In this combination, you can change only the value of policy name and the action label but not the hard-coded message. For example,
if (APPROVED.equals(state))
38 message = String.format(APPROVED_MSG, policyName, actionLabel);

Default Change Handler subflow

Use the Default Change Handler subflow to populate these change request fields with default values.
  • Requested by
  • Justification
  • Implementation Plan
  • Backout plan
  • Test Plan
  • Short Description
  • Description
  • Start Date
  • End Date
  • Risk Impact Analysis

The Default Change Handler subflow overrides the field values that were populated using a template while creating the change request record.

If desired, you can write a custom subflow in place of this flow by modifying the [sn_devops.change_request_handler_subflow] DevOps property.

Custom change request templates

When you enable change control in the ServiceNow DevOps step , you can select a custom template to populate fields automatically while creating the change request. The change request Category field is automatically set to DevOps.
Note: Do not configure the Category and changeType fields from the custom template.

The type of change request corresponds to the change request table in global scope.

Automatic change request related lists

For a change request automatically created by DevOps, the Category field is automatically set to DevOps, and these related lists are added:
Commits
Commits associated with the change request.
Work Items
Work items associated with the change request.
Artifact Versions

List of artifact versions associated to the package linked to pipeline execution for packages created before the change request is approved.

If no package is linked to the pipeline execution, then the list is empty.

Test Summaries (replaces Test Results related list)

List of test summaries for a pipeline execution associated with an artifact, package, or task execution before the change request.

See Test Results for more details.

Software Quality Summary
List of software quality summaries for a pipeline execution associated with an artifact, package, or task execution before the change request.
Security Summaries
List of security summaries for a pipeline execution associated with an artifact, package, or task execution before the change request.
Note: Security scan results on the change record associated to a pipeline execution with a linked package are also displayed in the Security Summaries tab.

DevOps Change Related Lists

Note: Implementation details from the orchestration tool are automatically added to the Work notes field on the change request form. Detail added to the work notes is limited to 5 KB of the task execution log for the step.

Custom change request process

These DevOps change properties are available to customize your change request flow.

  • DevOps change request implement state
  • DevOps change request post implement state
  • DevOps change request cancel state
  • DevOps change request approval text

To customize your change request flow, you must first create a System Definition > Choice List. For example, DevOps_Implement (value - 10).

Then, add the choice list to System Definition > Script Include > ChangeRequestStateHandlerSNC.

Once you have created the choice list and added it to the script include, you can update DevOps change properties with the new choice list values. For example, DevOps change request implement state -10.

DevOps Risk Condition

You can use the DevOps risk and impact calculation based on committer risk score.

This condition is inactive by default.

Test Results related list

Lists the tests that were run in a pipeline after a package was created. If no package was created, then the list includes the tests that were run after an artifact version was created.

Scenarios:

A package is created in the pipeline, but no artifact versions are registered.
  • If the change request is created in the package creation stage:

    No test results are displayed because a package is not yet linked to the pipeline execution.

  • If the change request is created in a stage after the package creation stage:

    Build test summaries include those associated with stages after the package creation stage, up to the change-controlled stage.

Artifact versions are registered, but no package is created.
  • If the change request is created in the artifact version stage:

    No test results will be displayed, because no tests are associated until the task execution is completed.

  • If the change request is created in a stage after the artifact version stage:

    Build test summaries include those in the artifact version stage, as well as the stages afterward, up to the change-controlled stage.

Both artifact versions and package are created in the pipeline.
  • If the change request is part of the stage after artifact version and package creation stages:

    Build test summaries include those associated with the package creation stage, as well as the stages afterward, up to the change-controlled stage.

  • If the change request is part of the package creation stage, and artifact versions are created as part of an earlier stage;
    • or the change request is created in a stage (not package creation) after the artifact version stage, but before package creation stage;
    • or the change request is part of the package creation stage and artifact versions are created as part of an earlier stage:

    Build test summaries include those associated with the artifact version stage, as well as stages afterward, up to the change-controlled stage.

Pipeline executions view

You can view pipeline activity by navigating to DevOps > Orchestrate > Pipeline Executions.

DevOps pipeline execution