Pipelines and Deployments workflow

  • Release version: Australia
  • Updated May 7, 2026
  • 4 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 Pipelines and Deployments workflow

    This workflow guides ServiceNow customers through the app deployment process in App Engine Management Center (AEMC) for versions 24.1.2 and later. It details how deployment requests move through pipelines from submission to final deployment, including validation, approvals, testing, and production deployment with Change Management integration.

    Show full answer Show less

    Workflow Process

    • Submission: The requester submits an app deployment request via App Engine Studio, Creator Studio, or ServiceNow Studio, triggering the workflow.
    • Initial Validation and Publication: The system validates the payload, fetches the App Manifest, creates a deployment request, sends a notification email, and publishes the app to the Application Repository.
    • Error Handling: If publication errors occur and severity is “Error,” the system creates an approval step before proceeding.
    • Next Environment Check: The workflow checks the next environment in the pipeline. If none exists, it notifies the requester that the request is closed and the app is published. If an environment exists, it updates the deployment request and waits for approval.
    • Approval Outcomes: If the approval is denied, the requester is notified and the request closes. If approved, deployment actions vary based on the target environment.

    Target Environment Actions

    • Testing Environment:
      • Deploys the app if not present.
      • Runs Scoped App Definitions Instance Scan and other test suites defined in the Scan Suites table on the Testing instance.
      • Runs the Application Deployment Test Suite via Automated Test Framework (ATF).
      • Logs test results to the Deployment Environment Result table and Activity Stream.
      • Returns to error checking step.
    • Production Environment:
      • Starts scheduled deployment integrated with Change Management.
      • Creates a change request using a template configured during Guided Setup.
      • Registers the app as a Configuration Item (CI) if not already registered and adds it to the change request.
      • Monitors change request state, waiting for the "Implement" state before scheduling deployment tasks.
      • If the change request is rejected or canceled before deployment, the requester is notified and the request is closed.
      • Schedules and executes deployment based on the Planned Start Date, then closes related tasks and requests.
    • Other Environments: Deploys the app if it is not already available and then loops back to the submission trigger.

    Notifications and Workflow Completion

    Throughout the workflow, the system sends email notifications from the Controller instance to keep the requester informed about request creation, approval status, errors, and closure. The workflow concludes when the app is successfully deployed or the request is closed due to rejection or errors.

    As you manage requests for app deployment in App Engine Management Center (AEMC), use this workflow to understand how app deployments move through your pipelines in versions 24.1.2 and later.

    Figure 1. Pipelines and Deployments workflow
    Infographic depicting a standard pipeline deployment in App Engine Management Center.
    In this workflow:
    1. The requester selects Submit in App Engine Studio, Creator Studio, or ServiceNow Studio, which triggers the main flow.
    2. The system performs the following tasks behind the scenes:
      1. Validates the payload.
      2. Fetches the App Manifest from the sys_app record on the source instance.
      3. Creates a deployment request on the controller instance.
      4. Sends an email from the controller instance to notify the requester that the request was created.
      5. Publishes the application to the Application Repository.
    3. The system performs different actions depending on if there are errors or not during publication.
      1. If there are errors in the app publication, and the error severity is Error, then the system creates and waits for approval for the updated record.
      2. If there are no errors, or if there are errors, but the error severity isn’t Error, then the system looks up the next environment on the Pipeline record.
        1. If the next environment doesn’t exist, the system sends an email from the Controller instance to notify the requester that the request was closed and the app has been published to the target instance. This action ends the workflow.
        2. If the next environment does exist, the system updates the Target environment field on the deployment request to the next environment. Then, the system creates and waits for approval for the updated record.
    4. The system performs different actions depending on if the new record was approved.
      1. If the record isn’t approved, the system sends an email from the Controller instance to notify the requester that the request wasn’t approved and the request has been closed. This action ends the workflow.
      2. If the record is approved, and if the Target environment is Testing, then the system performs the following actions:
        1. Deploys app to test environment, if the app is not available there.
        2. Runs the Scoped App Definitions Instance Scan and any other suites on the Scan Suites [[scan_suites]] table on the Testing instance.
          Note:
          The Scan Suites table should be populated on the Controller instance.
        3. Runs the Application Deployment Test Suite Automated Test Framework (ATF) suite and any suites on the Scan Suites [scan_suites] table on the Testing instance.
        4. Writes Instance Scan and ATF test results to the Deployment Environment Result table and to the Activity Stream on the deployment request.
        5. Returns the workflow to step 3, where it checks for errors.
      3. If the record is approved, and the Target environment is Production, the app begins the scheduled deployment process with Change Management integration.
        1. The App Engine admin selects Approve & Create Change request. A change request is created based on the template chosen during Guided Setup.
        2. The system performs different actions depending on if the app is registered as a configuration item (CI).
          1. If the app is not registered as a CI, the system registers the app as a CI and then adds the affected CI to the change request.
          2. If the app is registered as a CI, the system adds the affected CI to the change request.
        3. The system performs different actions depending on if the change request is in the Implement state.
          1. If the change request state is not Implement, and the state is not Assess or Authorize, the system sends an email from the Controller instance to notify the requester that their request was not approved and has been closed. This ends the workflow.
          2. If the change request state is not Implement, and the state is Assess or Authorize, the system waits for the state to be Implement.
          3. If the change request is in the Implement state, the system creates a change task to schedule the app deployment.
        4. If the change request state is Implement and the Planned Start Date is not Now or in the past, the system waits for those two conditions to be true
        5. If the change request state is Implement and the Planned Start Date is Now or in the past, but the request is Rejected or Cancelled, the system sends an email from the Controller instance to notify the requester that their request was not approved and has been closed. This ends the workflow.
        6. If the change request state is Implement and the Planned Start Date is Now or in the past, the system schedules the app deployment to Production based on the Planned Start Date in the change request. The system closes the change task, and then closes the deployment request. This ends the workflow.
      4. If the record is approved, and the Target environment isn’t Testing or Production, then the system deploys the app to the target environment, if it isn't available there.

        The workflow starts over when a requester selects Submit again in App Engine Studio, Creator Studio, or ServiceNow Studio.