--- 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 --- # Change request creation with DevOps data retrieval errors # Change request creation with DevOps data retrieval errors {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 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 Change request creation with DevOps data retrieval errors This feature enables ServiceNow customers to create change requests even if errors occur during DevOps data retrieval from supported pipeline tools such as Azure DevOps, GitHub Actions, GitLab, Jenkins, and Harness. This is controlled by theEnable change request creation even with errors in DevOps data retrievalproperty. Show full answer Show less When enabled, change requests will be created regardless of errors in retrieving data like work items, commits, test summaries, or security summaries. Retrieved data is linked to the change request, and error details are communicated both in the third-party console and within the change request's comments and worknotes. If the property is disabled, pipelines abort on errors and no change request is created. ## Approval Process Change requests created with partial DevOps data set the **ischangewithpartialdata** policy input to True, enforcing manual approval for these changes. This allows approvers to verify the incomplete data before approving or rejecting. ## Pipeline UI and Behavior * Errors during change request creation are highlighted with a yellow stage card in the pipeline UI. * In cases where a build (CI) pipeline triggers a release (CD) pipeline, data from the build pipeline may be associated with the change request even if some errors exist. In this scenario, the partial data flag is false, and normal approval flows apply. ## Callback Timeout and Pipeline Handling If an inbound pipeline event waits too long, exceeding the timeout set by the **sndevops.changerequestcallbacktimeout** property (default 120 minutes, minimum 60), the pipeline is aborted and the error logged both in the third-party console and the step execution callback record. For GitHub, GitLab, and Harness pipelines using custom change automation actions, polling intervals must be configured to synchronize change status properly. If notifications fail to reach ServiceNow DevOps, this can cause delays or unnotified pipeline termination by the third-party tool's default timeout. ## Upgrade Considerations After upgrading, the property to enable change request creation with DevOps errors is disabled by default, preserving existing behavior (pipeline abort on error). Customers can enable this property to allow change creation despite data retrieval errors, improving visibility and automation continuity for change approvers and development teams. ## Limitations If the property is enabled and an Azure DevOps artifact package step fails, the change request is created without the artifact data, but no error notification is provided in worknotes, step execution comments, or the Azure DevOps console log. Create change requests even with errors in DevOps data retrieval. ## Change request creation overview {#change-request-creation-with-devops-data-retrieval-errors__section_vtc_3qz_2bc} Note: Change request creation with DevOps data retrieval errors is supported only for Azure DevOps, GitHub Actions, GitLab, Jenkins, and Harness pipelines. You can create a change request with or without errors in DevOps data retrieval. This functionality can be controlled by the Enable change request creation even with errors in DevOps data retrieval property. When the Enable change request creation even with errors in DevOps data retrieval property is enabled, and an error occurs in retrieving DevOps data like work items, commits, test summaries, or security summaries, the corresponding change request is still created. The data that can be retrieved will still be associated with the change request. For the data that can't be retrieved, the reason for the error will be notified to the user in the third-party console, and the same information will also be added in the Change Comments field in the Step Execution record and the change Worknotes. If the Enable change request creation even with errors in DevOps data retrieval property isn't enabled, a change request is created only when there's no error in any step of a pipeline run. When an error occurs, the pipeline is aborted and the reason for the error is added in the inbound event's Processing details field, and the same is notified to the user in the third-party console. 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."). ## Approval for change requests with DevOps data retrieval errors {#change-request-creation-with-devops-data-retrieval-errors__section_cxs_mqz_2bc} For change requests created with DevOps data retrieval errors, the is_change_with_partial_data policy input is set to True for all the change approval policies. Only a manual change approval decision is applied to such changes so that you can approve or reject the change after manually verifying the DevOps data in it. In the DevOps Gather Change Policy Data subflow, the Is change with partial data action determines whether a change is created with DevOps data retrieval errors or not. ## Pipeline UI for change requests with DevOps data retrieval errors {#change-request-creation-with-devops-data-retrieval-errors__section_sfn_4qz_2bc} When a change request gets created with DevOps data retrieval errors, the card specifying the stage where the error occurred will be displayed in the Yellow color. Note: If your build pipeline (CI) is set up to trigger a release (CD) pipeline and a change is created in the release pipeline, the data is collected from the build pipeline and associated with the change request. There may be a situation where ServiceNow DevOps Change Velocity will receive and process the release pipeline events before build pipeline events. In this case, the change will be created with DevOps data from the build pipeline even though there's an error in retrieving some of the data. You can observe this behavior even though the Enable change request creation even with errors in the DevOps data retrieval property is enabled. Also, the is_change_with_partial_data policy input will be false in this case, and the approval process will be applied in the way it's defined in the approval flows unlike always manual in case of change requests with DevOps data retrieval errors. ## Callback timeout {#change-request-creation-with-devops-data-retrieval-errors__section_rnm_zqz_2bc} If an inbound event goes into the waiting state during a pipeline run, the system tries to process the change until the timeout value in the sn_devops.change _request_callback_timeout property is exceeded, after that the pipeline is aborted. The reason for the error is displayed in your third-party tool's console logs. When a pipeline is canceled because of callback timeout, the same information is added in the callback record of the corresponding step execution. You can contact your DevOps admin to increase the timeout value in the sn_devops.change_request_callback_timeout property. The default value of this property is 120 minutes, and the minimum value is 60 minutes. 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."). Note: If you are using GitHub change automation custom action, GitLab Docker change automation custom action, or Harness Docker change automation custom action in your corresponding pipeline to create change requests, you need to provide the interval in the custom action, which enables GitHub, GitLab, or Harness to poll ServiceNow DevOps for the change status. When the change reaches an appropriate state in ServiceNow within the specified interval, the appropriate status depending on the outcome of the change will be sent to GitHub, GitLab, or Harness pipeline, which will resume or abort the pipeline. See [ServiceNow DevOps custom actions from GitHub marketplace](https://www.servicenow.com/docs/8IIHLttsKDPIeqy0xNUBZg#servicenow-devops-custom-actions-from-github-marketplace "Use the custom actions from the GitHub marketplace to collect scan data, manage workflows, and update change request details.") and [Implement custom actions for pipelines using Docker image](https://www.servicenow.com/docs/lyDd5Y1L9yyAuDzJFwe0tg "Use the ServiceNow custom actions to collect data related to change request creation, Sonar scan, artifact registration, and package registration in your pipeline with the help of the generic Docker Container Image.") for more details. So, when your pipeline with the change custom action is run, and if any of the step notification from GitHub, GitLab, or Harness did not reach ServiceNow DevOps, then the association of callback, step execution, and task execution will not happen in ServiceNow DevOps. As the association is not available, the change will not be created and ServiceNow DevOps will wait until the association is in place. At the same time, GitHub, GitLab, or Harness will poll ServiceNow for the change status until the time specified in the interval is reached. If the interval is passed and also the timeout specified in the sn_devops.change_request_callback_timeout property is reached, ServiceNow DevOps will not terminate your pipeline as it should but will leave it for the default timeout set in the GitHub, GitLab, or Harness step that will eventually terminate the pipeline. The important information in this scenario is that ServiceNow DevOps will not be able to notify the user that the step events did not reach ServiceNow DevOps in the GitHub, GitLab, or Harness console logs. ## Upgrade {#change-request-creation-with-devops-data-retrieval-errors__section_kqx_lrz_2bc} After you upgrade, the property will be set to false by default. Your current change process will function as is, but the only difference you'll see is that, when an error occurs in retrieving DevOps data the pipeline is aborted (instead of waiting indefinitely) and the reason for the error is added in the inbound event Processing details field, and the same is notified to the user in the third-party console. If you want to create change requests with errors in retrieving DevOps data and also not fail your pipeline, you can enable the Enable change request creation even with errors in DevOps data retrieval property. This provides value to your change approvers and AppDev teams by getting the changes created automatically with DevOps evidence that is gathered and appropriately notified in the change request work notes and third-party console logs with errors or data that may be missing. ## Limitation {#change-request-creation-with-devops-data-retrieval-errors__section_phq_5rz_2bc} If the Enable change request creation even with errors in DevOps data retrieval property is enabled, and the ADO artifact package step in your pipeline results in error, the change will be created without ADO artifacts associated with it, but the corresponding error will not be notified in Worknotes, or Step Execution change comments, or in the ADO console log.