---
sourceDocument: Australia IT Service Management
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-service-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# Log change request state

# ServiceNow DevOps change request state in Jenkins pipeline logs {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 ServiceNow DevOps change request state in Jenkins pipeline logs

This feature allows ServiceNow customers to integrate change request state updates directly into Jenkins pipeline logs using the Jenkins Snippet Generator utility.
Developers and pipeline operators can monitor change request statuses and related policy decisions in real-time within the Jenkins console logs, enhancing visibility and automation during CI/CD processes.
Show full answer Show less  

## Key Features

* **Pipeline Syntax Integration:** Use the Jenkins Snippet Generator to create a `SnDevOpsChange` pipeline step snippet that tracks change request states and policy conditions.
* **Configurable Variables:**
  * **Polling Interval:** Sets how frequently Jenkins polls ServiceNow (in seconds) to update change states in the logs when key fields change (state, assignment group, approvals, planned dates, details).
  * **Change Creation Timeout:** Defines timeout for change request creation; on timeout, Jenkins checks creation status and either aborts or resumes the pipeline based on the abort flag.
  * **Abort on Change Creation Failure:** Controls whether the pipeline aborts if the change request is not created within the timeout.
  * **Change Step Timeout:** Sets timeout for ongoing change steps; on timeout, Jenkins checks status and resumes or aborts pipeline accordingly.
  * **Abort on Change Step Timeout:** Determines pipeline behavior if change step is still active after timeout.
  * **Ignore Error Option:** Allows preventing pipeline failure if there is an error in fetching change state.
* **Change Request Details in Logs:** Logs display key change request information including number, details, status, sysid, type, risk, priority, change state, planned start/end dates, and a direct URL.
* **Policy Condition Evaluation:** When policies like DevOps Change Request Advanced Automation are active, the pipeline logs include policy evaluation outcomes such as auto-approve, auto-reject, or manual approval decisions.
* **Supported Policies and Logging Behavior:**
  * DevOps Model Change Policy: Logs on change creation and state updates.
  * DevOps Change Request Minimal Automation Policy: Logs with change decisions and related policy conditions.
  * DevOps Change Request Advanced Automation Policy: Logs with detailed decisions and policy conditions.
* **Policy Input Fields and Operators:** Policy conditions logged include inputs such as code coverage, failed tests, number of outages/incidents, risk, commits, and more, using operators like =, !=, \<, \>, ISNOTEMPTY, BETWEEN, SAMEAS, etc.
* **Custom Fields:** If custom fields are added to policies, they must be manually included in the flow for evaluation and logging.
* **Error Handling:** If change request creation fails, the failure reason and state are logged in the pipeline console.

## Practical Application for ServiceNow Customers

By configuring the `SnDevOpsChange` step in Jenkins pipelines, customers can:

* Gain real-time visibility of ServiceNow change request statuses directly within Jenkins pipeline logs.
* Automate and monitor change request lifecycle and related policy decisions without leaving the CI/CD environment.
* Control pipeline execution based on change request creation and change step status, improving release governance.
* Diagnose issues quickly when change requests fail to create or progress as expected by reviewing detailed logs.

This integration streamlines collaboration between development and IT service management teams, ensuring change requests are accurately tracked and policies are enforced during automated deployments.  
You can use the Jenkins Snippet Generator utility to configure how and when the change state and the
corresponding policy conditions must be displayed in the Jenkins pipeline job logs. This enables developers to view the status of the change in the console logs of the pipeline itself.  
To generate a step snippet, navigate to the Pipeline Syntax from a configured pipeline, select the SnDevOpsChange step from the Sample Step list, and update the values for the change state variables in the step. Select the ignore error option to prevent job failure if there is an error. Select Generate Pipeline Script to create a snippet. You can copy and paste the snippet into the pipeline to start receiving the change state notifications. Update the following variables in the SnDevOpsChange step to receive change state notifications:

* Polling Interval: Specifies the frequency (in seconds) at which Jenkins polls ServiceNow for the change status and updates the console logs with the status. The change status is updated in the console logs only when the Change state transitions, Assignment Group updates, Approval updates, Planned Start/End date, or Change Details (if any) fields are updated.  
  Note:  
  If no value is entered in the field, polling interval check won't be run to update the change status in the console logs.
* Change Creation Timeout: Specifies the change creation timeout value in seconds. On timeout, Jenkins checks the change creation status in ServiceNow. If the change did not get created, the pipeline is resumed or aborted based on the Abort on change creation failure flag. By default, the pipeline is aborted when timeout is specified and the Abort on change creation failure flag is selected.  
  Note:  
  If no value is entered in the field, change creation timeout check won't be run to update the pipeline.
* Abort on change creation failure: Abort or resume the pipeline if change is not created till the change creation timeout.
  * Selected: Abort
  * Cleared: Resume
  {#change-request-state-in-jenkins-pipeline-logs__ul_wpq_lvg_wwb}
* Change Step Timeout: Specifies the change step timeout value in seconds. On timeout, Jenkins checks the change step status in ServiceNow. If the change step is still in progress, the pipeline is resumed or aborted based on the Abort on change step timeout flag. By default, the pipeline aborted when timeout is specified, and the Abort on change step timeout flag is selected.  
  Note:  
  If no value is entered in the field, change step timeout check won't be run to update the pipeline.
* Abort on change step timeout: Abort or resume the pipeline if the change step is still in progress on change step timeout.
  * Selected: Abort
  * Cleared: Resume
  {#change-request-state-in-jenkins-pipeline-logs__ul_vkc_wvg_wwb}
{#change-request-state-in-jenkins-pipeline-logs__ul_apv_y5g_wwb}

You can navigate to the console logs in your pipeline to view the state of a change request when a change request is created or when the state of the change request is updated. The policy conditions
associated with the change request state will also be evaluated and displayed in the logs. For example, if the DevOps Change Request Advanced Automation policy is activated, the policy conditions will be evaluated and the
corresponding decision made (auto-approve/auto-reject/manual-approval) will be displayed in the logs.  
The following change request details are displayed:

* number
* details
* status
* sys_id
* type
* risk
* priority
* changeState
* plannedStartDate
* plannedEndDate
* changeRequestURL
{#change-request-state-in-jenkins-pipeline-logs__ul_az3_2p1_tcc}


The logs for policy conditions will be displayed for the base system change flows as follows:

* DevOps Model Change Policy: Only logs will be displayed on change creation and when the change state is updated.
* DevOps Change Request Minimal Automation Policy: Logs along with change decision and policy conditions corresponding to the change decision will be displayed.
* DevOps Change Request Advanced Automation Policy: Logs along with change decision and policy conditions corresponding to the change decision will be displayed.
{#change-request-state-in-jenkins-pipeline-logs__ul_y3x_1jt_xxb}  
The change policy input and decision conditions are stored in the Decisions \[sys_decision_question\] table. Logs will be displayed if the following fields and operators are used as input for policy conditions:

Fields
:
    * code_coverage
    * commits_without_work_item
    * integration_tests_failed
    * load_tests_failed
    * regression_tests_failed
    * num_of_outages_in_last_7_days
    * num_of_current_outages
    * num_of_open_incidents
    * total_num_of_commits
    * tests_passing_percent
    * risk
    * code_security
    * commits
    {#change-request-state-in-jenkins-pipeline-logs__ul_qkg_xjt_xxb}

Operators
:
    * \<=
    * \>=
    * !=
    * =
    * \<
    * \>
    * ISNOTEMPTY
    * ISEMPTY
    * BETWEEN
    * ANYTHING
    * NSAMEAS
    * SAMEAS
    * GT_FIELD
    * LT_FIELD
{#change-request-state-in-jenkins-pipeline-logs__ul_dst_kpt_xxb}  
Note:  
If any field is modified in a change policy other than the base system fields, then those fields must be manually added to the flow for policy conditions to be evaluated.

If a change request does not get created due to any issue, then the reason for the failure and the state is also logged in the console.

