---
sourceDocument: Australia IT Service Management
sourceDocumentLink: https://www.servicenow.com/docs/r/it-service-management
Release :
- australia
ft:locale :
- en-US
ft:publication_title :
- Australia IT Service Management
ft:clusterId :
- itsm
bundleId :
- itsm
workflow :
- Technology
---
# Accelerate your DevOps change process
# Accelerating your DevOps change process {#ariaid-title1}
* Release version: Australia
*
* Updated March 12, 2026
*
*  13 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 Accelerating your DevOps change process
This feature in ServiceNow DevOps Change Velocity streamlines and automates change request creation and approval within DevOps pipelines.
By enabling change acceleration, change requests are automatically generated during pipeline execution, facilitating faster and controlled deployments.
Change approval flows and policies automate approvals under defined conditions, reducing manual intervention and enhancing pipeline efficiency.
Show full answer Show less
Note: ServiceNow Change Management must be installed to use change acceleration.
## Change Control Process
* When enabled, change requests are automatically created in the Assess state to seek approval for pipeline stages or jobs.
* Change requests can either pause the pipeline awaiting approval or proceed without pausing if change receipts are enabled.
* Approved changes transition to Implement and then Closed states based on job success or failure.
* Unapproved or canceled changes mark related jobs as failed with clear console messages for Jenkins, GitHub, and Azure DevOps (ADO).
## Automatic Approval Using Flows and Policies
ServiceNow provides three base flows for automating change request approvals, customizable via Flow Designer:
* **Manual Approval Flow:** Default flow requiring manual approval, tracking change request states and resuming or terminating pipelines accordingly.
* **Minimal Automation Approval Flow:** Uses basic DevOps data and policies for auto-approval or rejection, with fallback to manual approval.
* **Advanced Automation Approval Flow:** Implements robust policies based on comprehensive DevOps data, scheduling changes and resuming pipelines automatically.
Only one flow should be active at a time to avoid conflicts. These flows update change request and pipeline execution states through callbacks, ensuring seamless integration with pipeline execution.
## Change Approval Policies
Policies define conditions and decisions for auto-approving, auto-rejecting, or requiring manual approval of change requests based on DevOps data such as commits, test results, risk scores, and security summaries. Default policies include:
* DevOps Model Change Policy
* DevOps Change Request Minimal Automation Policy
* DevOps Change Request Advanced Automation Policy
Policies can be customized or created anew to align with organizational requirements. Notifications facilitate prompt manual approvals when needed.
## Change Request Management Features
* **Default Change Handler Subflow:** Populates key change request fields automatically during creation; customizable via properties.
* **Custom Templates:** Allow automatic population of change request fields when enabling change control in pipelines, with Category defaulted to DevOps.
* **Related Lists:** Change requests automatically link to related commits, work items, artifact versions, test summaries, quality, and security summaries, improving traceability.
* **Custom Change Request Process:** Allows modifying change request states and approval texts to fit specific workflows.
* **Risk Assessment:** Utilizes committer risk scores to help evaluate change risk, supporting better decision-making.
## Pipeline Integration and Data Management
* Supports modeling pipelines from Azure, GitLab, Jenkins, and others, with visibility into pipeline executions and change requests.
* Enables management of pull requests and merges across GitHub, Bitbucket, and ADO within ServiceNow DevOps, integrating approval workflows.
* Artifacts and packages track development and testing activities, enabling synchronization of change records with pipeline progress.
* Supports importing and updating change request attributes via APIs, subflows, pipeline inputs, and automated flows for flexibility.
* Offers reduced instance load by allowing evidence collection without step-level pipeline processing for supported orchestration tools.
## Customization and Extensibility
* Flows and policies can be cloned and customized to meet organizational needs, with detailed logging and work notes for transparency.
* Properties allow fine-tuning of change request state transitions and behavior, including disabling automatic state transitions if required.
* Supports creating change requests with categories other than DevOps by adjusting properties, providing flexibility in change classification.
* Provides scripting support (e.g., DevOpsChangeRelationshipHelper) to retrieve related change request data programmatically.
## Practical Benefits for ServiceNow Customers
* Accelerates DevOps pipelines by automating change request creation and approvals, reducing manual delays.
* Improves compliance and governance through controlled, auditable change approval processes integrated directly into pipelines.
* Enables tailored automation flows and policies that reflect organizational risk tolerance and operational requirements.
* Enhances visibility into pipeline and change activity with linked DevOps data and detailed work notes.
* Supports diverse DevOps toolchains and workflows, providing a unified change management experience.
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](https://www.servicenow.com/docs/uBHHMv4DsgI5VM1mPhonMg "The ServiceNow Change Management application provides a systematic approach to control the life cycle of all changes, facilitating beneficial changes to be made with minimum disruption to IT services.") must be installed for change acceleration.
Enable and set up change control when you model your pipeline in DevOps:
* [Model an Azure pipeline in DevOps](https://www.servicenow.com/docs/Q6iZe2xLLdqx~4AoliT3Ag "Model an Azure pipeline by mapping the pipeline to an app, and mapping DevOps Change Velocity pipeline steps to Azure pipeline jobs.")
* [Model a GitLab basic CI pipeline in DevOps](https://www.servicenow.com/docs/PR2wJnDVYgCwFR1Xh~P2hg "Model a GitLab basic CI pipeline by mapping the pipeline to an app, and mapping DevOps pipeline steps to GitLab pipeline jobs.")
* [Model a Jenkins pipeline in DevOps](https://www.servicenow.com/docs/ep9QfKuP8Ay0r1oIbN1tYQ "Model a Jenkins pipeline by mapping the pipeline to an app, and mapping DevOps pipeline steps to Jenkins stages.")
{#dev-ops-change-acceleration__ul_xcf_mfc_wmb}
You can view details for active change requests by navigating to DevOpsOrchestratePipeline Change Requests.
## Change control process {#dev-ops-change-acceleration__section_wyf_slc_wmb}
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](https://www.servicenow.com/docs/Cy67V7Lf9sOXU2beB3VARQ "Use these properties to configure settings in the DevOps Change Velocity application.").
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](https://www.servicenow.com/docs/1IOGCXHTnX02RprvPaB2wg#dev-ops-change-acceleration__section_www_tzz_jjb).
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 {#dev-ops-change-acceleration__section_mf3_zfc_wmb}
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 {#dev-ops-change-acceleration__section_lmy_jwz_zyb}
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](https://www.servicenow.com/docs/access?context=flow-designer&version=australia&pubname=australia-application-development&ft:locale=en-US).
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.
{#dev-ops-change-acceleration__ul_egd_nxr_zyb}
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.
{#dev-ops-change-acceleration__table_xlb_syr_zyb__entry__2}
| DevOps flow | Default behavior |
|-|-|
| DevOps Change Request Manual Approval Flow | This flow is activated by default. With this flow, DevOps change requests must go through a manual approval process, where the flow waits for the change request to reach an eligible state (rejected, implemented, or specific implementation state). When reached, this flow will update the state of the step execution based on the state of the change request. If the change request is type-based, the flow will wait for the change to get rejected, implemented, or canceled. If the change request is model-based, the flow will wait for the change to get rejected, get canceled, or reach one of the implementation states defined in the model or the implement state specified in the DevOps property. This flow won't trigger for DevOps change requests whose model is a base system DevOps change model (DevOps or DevOps simplified) to avoid conflicts and errors. You can clone this flow and customize it to make changes. Ensure that the other DevOps flows are deactivated. |
| DevOps Change Request Minimal Automation Approval Flow | This flow gathers DevOps data and runs the DevOps Change Request Minimal Automation Policy, which determines if the change should be auto-rejected, auto-approved, or sent for manual approval. This flow is triggered for DevOps change requests whose type or model is set to normal. Activate this flow if you want to automate change request approvals, but start minimally. You can clone this flow and customize it to make changes. Ensure that the other DevOps flows are deactivated. You can also add the DevOps - Update Minimal Automation Policy Decision Reason action to this flow to update the policy decisions to the step execution change comment and the change request worknotes to know the reasons for the decision. You can add this action inside every decision block and specify the required input. |
| DevOps Change Request Advanced Automation Approval Flow | This flow gathers DevOps data and runs the DevOps Change Request Advanced Automation Policy, which determines if the change should be auto-rejected, auto-approved, or sent for manual approval. This flow is triggered for DevOps change requests whose type or model is set to normal. If the DevOps change request is approved, the flow will update the change request to the scheduled state, and the planned start date will be used to set the change request start date. On the change request start date, the flow will update the change request state to implement. After that the pipeline will be resumed. Activate this flow if you want to automate change request approvals with a robust change policy. You can clone this flow and customize it to make changes. Ensure that the other DevOps flows are deactivated. |
| DevOps Demo Change Automation flow | When demo data is installed, the DevOps Demo Change Automation flow is available where normal type of change request or normal model change request can be auto-approved based on the decision policies. As a part of demo data, the decision policies available are: * DevOps Low Risk Auto Approval policy, where the failed test count is zero . * DevOps High risk manual approval policy, where the failed test count is greater than zero . {#dev-ops-change-acceleration__ul_lvl_h1f_1zb} You can clone this flow and customize it to make changes. Ensure that the other DevOps flows are deactivated. |
[ ]
{#dev-ops-change-acceleration__table_xlb_syr_zyb}
To read guidelines on how to use flows, subflows, and actions more effectively, see [General guidelines for Workflow Studio flows, subflows, and actions](https://www.servicenow.com/docs/access?context=design-considerations-consolidated&version=australia&pubname=australia-build-workflows&ft:locale=en-US).
## Change approval policies {#dev-ops-change-acceleration__section_zzr_mwz_zyb}
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.
{#dev-ops-change-acceleration__ul_xbr_fbs_zyb}
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
{#dev-ops-change-acceleration__ul_it1_dcs_zyb}
For more information on change approval policies, see [Change approval policies](https://www.servicenow.com/docs/6VpgFyDKyBxzVRFkomYawA "In Change approval policies, approval definitions are used to generate approvals according to your business requirements.").
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:
The DevOps Change Request Advanced Automation Policy has the following conditions and criteria by default:
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.
{#dev-ops-change-acceleration__ul_jq4_zhb_gtb}
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](https://www.servicenow.com/docs/OCyz2Qqnl9MmjCkU5mmJVg "Apply your change approval policy in the Change Management Workflow Studio action to control the approval process for a change request. You can create user and group approvals according to a change approval policy record.").
## Change approval work notes {#dev-ops-change-acceleration__section_dyd_2bx_ycc}
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).
{#dev-ops-change-acceleration__ul_sq5_12x_ycc}
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 {#dev-ops-change-acceleration__section_zwl_y1p_k2c}
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
{#dev-ops-change-acceleration__ul_axl_y1p_k2c}
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](https://www.servicenow.com/docs/Cy67V7Lf9sOXU2beB3VARQ "Use these properties to configure settings in the DevOps Change Velocity application.").
## Custom change request templates {#dev-ops-change-acceleration__section_irr_sxf_llb}
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 {#dev-ops-change-acceleration__section_rph_v2z_jjb}
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](https://www.servicenow.com/docs/1IOGCXHTnX02RprvPaB2wg#dev-ops-change-acceleration__section_ccp_nbb_dlb) 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.
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 {#dev-ops-change-acceleration__section_www_tzz_jjb}
These [DevOps change
properties](https://www.servicenow.com/docs/Cy67V7Lf9sOXU2beB3VARQ "Use these properties to configure settings in the DevOps Change Velocity application.") 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
{#dev-ops-change-acceleration__ul_hln_lgb_kjb}
To customize your change request flow, you must first create a System DefinitionChoice List. For example, DevOps_Implement (value - 10).
Then, add the choice list to System DefinitionScript IncludeChangeRequestStateHandlerSNC.
Once you have created the choice list and added it to the script include, you can update
[DevOps change
properties](https://www.servicenow.com/docs/Cy67V7Lf9sOXU2beB3VARQ "Use these properties to configure settings in the DevOps Change Velocity application.") with the new choice list values. For example, DevOps change request implement state
-10.
## DevOps Risk Condition {#dev-ops-change-acceleration__section_x4j_zzg_k3b}
You can use the DevOps risk and impact calculation based on committer risk
score.
This condition is inactive by default.
## Test Results related list {#dev-ops-change-acceleration__section_ccp_nbb_dlb}
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.
{#dev-ops-change-acceleration__ul_gg5_23b_dlb}
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.
{#dev-ops-change-acceleration__ul_d3n_33b_dlb}
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:
{#dev-ops-change-acceleration__ul_chj_vxm_nsb}
Build test summaries include those associated with the artifact version
stage, as well as stages afterward, up to the change-controlled stage.
{#dev-ops-change-acceleration__ul_cd5_j3b_dlb}
## Pipeline executions view {#dev-ops-change-acceleration__section_vwt_bkc_wmb}
You can view pipeline activity by navigating to DevOpsOrchestratePipeline Executions.
* **[Customizing DevOps flows](https://www.servicenow.com/docs/qL5ZkK2bE2766F_f0ltR7w)**
Customize or recreate the DevOps Change Request Manual Approval, DevOps Change Request Minimal Automation Approval, and DevOps Change Request Advanced Automation Approval flows based on your requirements using a flow or a script.
* **[Automate DevOps change request creation](https://www.servicenow.com/docs/Pw_QtOjaK96KhuVzwFBcSQ)**
Modify your pipeline to automatically create a DevOps change request.
* **[Create a DevOps Change request and associate existing DevOps data --- Workspace](https://www.servicenow.com/docs/c6drU2CYKzv9z24~4i9c1Q)**
Create a DevOps change request and associate existing DevOps data through the Workspace UI.
* **[Create a DevOps change request and associate existing DevOps data --- Classic](https://www.servicenow.com/docs/XCCYk2w3eWyToCW77FjqNA)**
Create a DevOps change request and associate existing DevOps data through the Classic UI.
* **[DevOps change request without mandating category as DevOps](https://www.servicenow.com/docs/jk26zeeRipQdGgQCtn5cTA)**
Enable categorizing DevOps change request from DevOps properties. Change requests that are created as part of pipeline execution steps can be created with a category other than DevOps.
* **[Change request creation with DevOps data retrieval errors](https://www.servicenow.com/docs/YzoJ5L1iYGj3S1v4a8oQ1g)**
Create change requests even with errors in DevOps data retrieval.
* **[Artifacts and packages](https://www.servicenow.com/docs/ZGDdOnEWq330BJleYqX2_g)**
Artifacts and packages enable DevOps Change Velocity to track development and testing activities across a wide range of deployment and release models. This feature ensures that pipeline activity stored in the DevOps data model can be retrieved and applied when artifacts are created and released at different times or in different pipelines.
* **[DevOps Pipeline UI](https://www.servicenow.com/docs/yaj2dQuVNc7UKuimbU8Fug)**
Use the Pipeline UI to visualize interactions and results across a pipeline execution. This graphical view shows pipeline step progression and other details for each pipeline.
* **[Configuring DevOps change request details within the pipeline](https://www.servicenow.com/docs/JrPZPSHCjQRzCnCP7jFB5Q)**
Configure how the closure information, change state, and change request fields are updated from within a pipeline in the change step of the pipeline.
* **[DevOps change models](https://www.servicenow.com/docs/kYawifgINsRlYqcbPCDx_A)**
DevOps Change Velocity enables you to use fit-for-purpose change models that allow better flexibility in defining change models or processes to reflect modern development practices.
* **[Retrieve change request data using DevOpsChangeRelationshipHelper script](https://www.servicenow.com/docs/k1rcO3ggBdLIo7_ESsE6MQ)**
Retrieve data associated with a change request based on the specified relation type using the DevOpsChangeRelationshipHelper script include.
* **[Manage Pull Requests (PR) or Merge Requests](https://www.servicenow.com/docs/un~tmtb6kQPpriSe~U17NQ)**
Manage Jenkins, GitHub Actions, and Azure DevOps (ADO) pipeline's pull requests for GitHub, Bitbucket, and ADO coding sources from ServiceNow DevOps. You can enable the change approval process on your pull request to control pull request merge approvals from ServiceNow DevOps and monitor pull request details associated with the change request.
* **[DevOps change request attributes](https://www.servicenow.com/docs/ctgSJCQRNiXdd~HVa~sPGw)**
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.
* **[Import based evidence collection](https://www.servicenow.com/docs/WV1Uz4k4yrQmGb3xcw2m3g)**
Reduce instance overhead by skipping step-level pipeline processing for accelerated change management and evidence collection for GitHub Actions, Azure DevOps (ADO), Jenkins and GitLab orchestration tools.
*[\>]: and then