Change request creation with DevOps data retrieval errors

  • Release version: Xanadu
  • Updated July 31, 2025
  • 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 Change request creation with DevOps data retrieval errors

    This feature enables ServiceNow customers to create change requests even when there are errors retrieving DevOps data from supported pipeline sources such as Azure DevOps, GitHub Actions, GitLab, Jenkins, and Harness. This capability is controlled by theEnable change request creation even with errors in DevOps data retrievalproperty.

    Show full answer Show less

    When this property is enabled, change requests are created regardless of partial failures in fetching DevOps data like work items, commits, test summaries, or security summaries. Available data is still linked to the change request, while errors are logged visibly in the third-party console, change work notes, and step execution comments.

    If the property is disabled, the pipeline run is aborted upon any DevOps data retrieval error, preventing change request creation and notifying users of the failure in the inbound event processing details and third-party console.

    Key Features

    • Partial Data Handling: Change requests can be created with partial DevOps data, ensuring continuous change tracking even if some data retrieval steps fail.
    • Manual Approval Enforcement: Change requests created with partial data set the ischangewithpartialdata policy input to True, triggering manual approval processes to ensure thorough verification before proceeding.
    • Pipeline UI Indicators: Errors during change request creation are visually indicated with yellow cards specifying the stage where the error occurred, improving transparency.
    • Callback Timeout Management: The system respects a configurable timeout (default 120 minutes) for waiting on inbound events during pipeline runs, after which the pipeline is aborted and error reasons logged. Admins can adjust this timeout via the sndevops.changerequestcallbacktimeout property.
    • Custom Action Integration: For GitHub, GitLab, and Harness, custom actions require specifying polling intervals to synchronize change status, ensuring timely updates and preventing indefinite pipeline waits.
    • Upgrade Behavior: After upgrading, the property defaults to false, maintaining existing behavior of aborting pipelines on errors unless explicitly enabled.

    Practical Considerations

    • Enabling this property provides value by automating change request creation with available DevOps evidence and clearly communicating missing or error data to approvers and development teams.
    • Manual approval is required to handle change requests with partial data, ensuring human oversight when some DevOps information is unavailable.
    • There is a known limitation where errors in Azure DevOps artifact package steps do not generate error notifications in work notes, step execution comments, or the Azure DevOps console logs.
    • For pipelines triggering chained releases (build triggering release), data from the build pipeline may cause change requests to be created before release pipeline data is available, potentially affecting how partial data and approvals are handled.

    What to Expect

    With this feature enabled, ServiceNow customers can expect more resilient change request creation that tolerates partial DevOps data retrieval failures without pipeline interruptions. Approvers will have access to all collected data alongside clear notifications of any missing information, promoting informed decision-making. Pipeline UI enhancements and callback timeout configurations improve operational visibility and control over the change creation lifecycle.

    Create change requests even with errors in DevOps data retrieval.

    Change request creation overview

    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.

    Approval for change requests with DevOps data retrieval errors

    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

    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. Pipeline UI displaying error stage card in yellow for change with errors

    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

    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.

    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 and Implement custom actions for pipelines using 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

    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

    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.