---
sourceDocument: Brazil IT Service Management
sourceDocumentLink: https://www.servicenow.com/docs/r/it-service-management
Release :
- brazil
ft:locale :
- en-US
ft:publication_title :
- Brazil IT Service Management
ft:clusterId :
- itsm
bundleId :
- itsm
workflow :
- Technology
---
# Configuring DevOps change request details within the pipeline
# Configuring DevOps change request details within the pipeline {#ariaid-title1}
Release version: Brazil
Updated September 10, 2026
 5 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 Configuring DevOps change request details within the pipeline
This guide explains how ServiceNow customers can configure change request details, closure information, and change states directly within DevOps pipelines during the change step.
This configuration enables automatic updates to change requests based on pipeline execution results, improving integration between DevOps tools and IT change management processes.
Note that configuring change request details from within GitLab pipelines is not supported.
Show full answer Show less
## Key Features
* **Auto Close Change Feature:** Using the `autoCloseChange` parameter within the `changeRequestDetails` object, you can control whether a change request is automatically closed upon pipeline completion. Setting it to `true` updates the Close code, Close notes, Actual start/end dates, and closes the change request. Setting it to `false` updates closure information without closing the request.
* **Customizable Closure Behavior:** The default system subflow `sndevops.autoclosechange` manages closure updates. Customers can clone and customize this subflow to meet specific business needs.
* **Start and End Time Configuration:** The Actual start and end dates are derived from pipeline or stage start/end times by default. This can be overridden to use change request times via system properties (`sndevops.changerequest.autocloseallowoverridestarttime` and `sndevops.changerequest.autocloseallowoverrideendtime`).
* **Pipeline Setting Overrides:** The pipeline's `autoCloseChange` flag takes precedence over the Auto Close Change column value in ServiceNow, allowing flexible configuration at different levels.
* **Supported Pipelines and Limitations:** The auto close change feature applies only to basic pipelines with a single change request. Jenkins freestyle pipelines and change requests with change receipt enabled are not supported. Azure pipelines derive completion status from all stages, impacting closure logic.
* **Close Code Parameter:** The `setCloseCode` parameter controls whether the Close code and Close notes are updated upon stage completion. It defaults to `true` but is disabled when `autoCloseChange` is enabled.
* **Change Request Field Updates:** You can set or update change request fields from within the pipeline using the `attributes` parameter via the DevOps API endpoint `/devops/orchestration/changeControl`. Field values must match the change request schema.
* **Unsupported Fields:** Fields like `risk`, `impact`, and `riskimpactanalysis` are calculated automatically by ServiceNow and cannot be set via the pipeline.
## Practical Application and Expectations
ServiceNow customers can use this capability to automate and synchronize change request lifecycle updates with DevOps pipeline executions, reducing manual effort and improving accuracy in change management records. By configuring the `autoCloseChange` and `setCloseCode` parameters appropriately, customers control whether changes close automatically or only update relevant fields. Customers can also customize the closure subflow for tailored business processes.
Field updates allow setting critical change request attributes such as assignment group, priority, category, and business service directly from pipelines, ensuring change requests reflect the most current context.
Upgrading customers must reconfigure orchestration tools before using these features for GitHub and Azure pipelines to ensure compatibility.
## Important Considerations
* Auto close change applies only when a single change request is associated with a pipeline; otherwise, only the latest change is considered.
* The pipeline-level `autoCloseChange` flag overrides ServiceNow table column settings.
* Unsupported pipeline types and scenarios (e.g., GitLab pipelines, Jenkins freestyle) will not benefit from auto close features.
* Ensure dependent required fields are set when updating change request fields to avoid cancellation of change and step executions.
* Risk and impact fields are calculated by ServiceNow and must not be manually set.
Configure how the closure information, change state, and change request fields are updated from within a pipeline in the change step of the pipeline.
Note:
Configuring change request details from within a GitLab pipeline isn't supported.
The system variable, by default, points to the Default subflow to auto close a change in the base
system. The DevOps auto close change on pipeline completion subflow (sn_devops.auto_close_change) determines how the closure information, change state, and change request fields are
updated when a pipeline is completed. If you want to specify a custom subflow that must be activated when a pipeline is completed, you can clone this subflow and customize it according to your requirements.
Closure information and change request attributes are contained with the
changeRequestDetails object.
## Auto close change {#dev-ops-config-change-details__section_ts2_c1b_5yb}
Set the autoCloseChange parameter to true/false in the changeRequestDetails object when creating a change from a pipeline to update the Close code and Close notes fields and close the change request when a pipeline is completed. The Actual start date and Actual end date field values are also updated when the pipeline is completed. The date values are based on the pipeline's start time or the pipeline's first stage's start time, and the pipeline's end time or the pipeline's last stage's end time.
Note:
If you want the change request start and end time to be considered instead of the pipeline's, you can set the sn_devops.change_request.auto_close_allow_override_start_time and sn_devops.change_request.auto_close_allow_override_end_time property to false by navigating to All \> System Properties \> All Properties.The close notes will be suffixed with text specifying that the closure information has been updated based on the Auto close change feature.
If set to true, the Close code and Close notes fields will be updated and the system will try to close the change request when the pipeline is completed.
If set to false, the Close code and Close notes fields will be updated when a pipeline is completed but the change request won't be closed.
You can also set the Auto close change field value for a pipeline in the
ServiceNow application. If you select Update Change Only, the Close code and Close notes fields will be updated when a pipeline is completed, and if you select
Update and Close Change, the change request will also be closed along with updating the closure information.
Based on whether the auto close change is specified in the pipeline or column, the final state considered will be as follows:{#dev-ops-config-change-details__simpletable_vhd_nly_2zb__entry__3}
| autoCloseChange flag in change request attributes | Auto Close Change column value (sn_devops_pipeline) | Final state |
|-|-|-|
| True | Update Change Only | Updates change and moves state to close |
| False | Update and Close Change | Only updates the change |
| - | Update Change Only | Only updates the change |
| - | Update and Close Change | Updates change and moves state to close |
[ ]
{#dev-ops-config-change-details__simpletable_vhd_nly_2zb}
Note:
The value specified for the autoCloseChange attribute in the pipeline takes precedence over the value specified in the Auto Close Change column in ServiceNow.
Note:
* The auto close change feature is only applicable for basic pipelines with a single change created on it. If there are multiple changes, the latest change will be considered for auto close.
* The auto close change feature isn't supported for Jenkins freestyle pipelines and change requests where the change receipt feature is enabled.
* For an Azure release pipeline, the pipeline completion state is derived by consolidating the state of each stage in the pipeline. If even one stage fails, the pipeline will be considered unsuccessful. If even one stage is partially successful, the pipeline will be considered successful with issues.
{#dev-ops-config-change-details__ul_j4j_ctd_vyb}
## Upgrade information {#dev-ops-config-change-details__section_d2f_jh5_c1c}
If you're upgrading, you must re-configure your orchestration tool before setting the autoCloseChange parameter for GitHub and Azure build pipelines.
## Set Close Code {#dev-ops-config-change-details__section_crb_rmc_v4b}
Set the setCloseCode: parameter to true/false based on the desired behavior. Default is true.
If set to true, the Close code and Close notes fields
are updated as specified in the change step attributes and the change request is moved to post-implement when a stage is completed. You can override this behavior by enabling the Auto close code feature.
The setCloseCode feature will get disabled when autoCloseChange is enabled and set to true or false. For more information, see [Auto Close Change](https://www.servicenow.com/docs/rc5DP1PfKCqXoeEDCHuP_A#dev-ops-config-change-details__section_ts2_c1b_5yb). Use the autoCloseChange feature for more accurate change request details.
If set to false, when the job or pipeline has completed, the change request isn't updated and remains in the Implement state.
* Closure Information in the change request isn't set (Close code and Close notes fields are left empty).
* A link to the step execution is added to the Work notes.
{#dev-ops-config-change-details__ul_cjt_hwx_3wb}
## Change request fields {#dev-ops-config-change-details__section_zq3_wmc_v4b}
Set change request field values within the pipeline for the change request template specified.
* Use the attributes: parameter to set field values.
* Use the [DevOps - POST
/devops/orchestration/changeControl](https://www.servicenow.com/docs/access?context=devops-api&version=brazil&pubname=brazil-api-reference&ft:locale=en-US) endpoint of the DevOps API.
{#dev-ops-config-change-details__ul_rqn_c5c_v4b}
Note:
* If a specified field has a dependent field that is required, you must set that attribute as well.
* If the attribute for the dependent required field isn't set, change request and related step execution are canceled, and work notes are updated.
{#dev-ops-config-change-details__ul_byp_vkp_gqb}
Field values within the attributes: parameter are key-value pairs.
Meaning, the key is the field name within the template and the value is the information to
populate in the field.
You can use the changeControl API to specify fields such as type, cmdb_ci, template, assignment_group
business_service, standard_change_template, chg_model and create a change request.
When attributes are passed for change, the order of priority is as follows:
1. Change request fields or changeControl API.
2. Values in the Step record.
3. Values provided in the Change Request template.
{#dev-ops-config-change-details__ol_hhn_4g4_41c}
Note:
When configuring change requests from within the pipeline, change type and template fields are always taken from one source. You can't use a combination of attributes from the API request and the change request form.
You can update change fields by passing values from the pipeline for all the supported change fields. The only exception is the list of unsupported fields in the following table.
|-|-|
| Unsupported fields | * risk * impact * risk_impact_analysis {#dev-ops-config-change-details__ul_lhd_l5q_54b} |
| Supported fields | All remaining fields in the Change Request \[change_request\] table. |
[Table 1. Change request fields supported]
{#dev-ops-config-change-details__table_jtr_dbr_54b}
Fields such as risk and impact are calculated fields and therefore can't be entered as user inputs. These values are automatically derived based on the change data and the configured
risk and impact conditions. To understand how risk and impact are calculated, see [Add or modify risk and impact conditions](https://www.servicenow.com/docs/S94ilI~4mvR9GjLQ7P8zqQ "You can define risk calculation rules on which the risk and impact of a change are calculated. Change Management - Change Risk Calculator is activated by default in the base system."). Once the risk and impact values are calculated, the Risk impact analysis field is automatically populated with the resulting risk and impact
information.
Note:
The attribute name must match the change request field name, and the value specified must be valid.
## Sample JSON payload {#dev-ops-config-change-details__section_qtj_c4c_v4b}
{
"callbackURL":"http://192.168.0.4:3000/jenkins/sn-devops/pipeline_839b7605-b98d-4831-bc87-96829de7da37",
"orchestrationTaskURL":"http://192.168.0.4:3000/jenkins/job/java_sample_tests#deploy/",
"isMultiBranch":"false",
"orchestrationTaskName":"java_sample_tests#deploy",
"orchestrationTaskDetails":{
"triggerType":"upstream",
"upstreamTaskExecutionURL":"http://192.168.0.4:3000/jenkins/job/java_sample_tests/129/execution/node/35/wfapi/describe",
"taskExecutionURL":"http://192.168.0.4:3000/jenkins/job/java_sample_tests/129/execution/node/50/wfapi/describe"
},
"changeRequestDetails":{
"setCloseCode":false,
"attributes":{
"sys_created_by":"1832fbe1d701120035ae23c7ce610369",
"sys_updated_by":"56826bf03710200044e0bfc8bcbe5dca",
"requested_by":{
"name":"Abel Tuter"
},
"watch_list":[
{
"name":"Abel Tuter"
},
{
"name":"Aileen Mottern"
},
{
"name":"Alejandra Prenatt"
},
"56826bf03710200044e0bfc8bcbe5dca"
],
"work_notes_list":[
"56826bf03710200044e0bfc8bcbe5dca",
"46c6f9efa9fe198101ddf5eed9adf6e7",
"d8f57f140b20220050192f15d6673a98"
],
"assigned_to":"1832fbe1d701120035ae23c7ce610369",
"category":"Service",
"sys_created_on":"2021-02-09 18:58:41",
"priority":"2",
}
}
}
## Pipeline examples {#dev-ops-config-change-details__section_xs4_xnc_v4b}
Figure 1. Change request details - Azure pipeline
Figure 2. Job-level settings --- Jenkins
Figure 3. Change request details - Jenkins Figure 4. Change request details - GitHub