Create a change request in Service Operations Workspace

  • Release version: Australia
  • Updated March 12, 2026
  • 9 minutes to read

    • Track modifications to a supported configuration item (CI) by using a change request. You can record information such as the reason for the change, and the change type, priority, and risk.

    Before you begin

    Role required: itil or admin

    Note:
    You must have the sn_devops.viewer role to view or add DevOps data to a change request.

    Procedure

    1. Create a new change request.
      SourceDescription
      Change list
      1. Navigate to a list of changes.
        Note:
        The following lists are available:
        • Open
        • Closed
        • All
      2. Select New.
      From a change template
      1. Navigate to a list of changes.
        Note:
        The following lists are available:
        • Open
        • Closed
        • All
      2. Select New.
      3. Select Templates.
      4. Search for and select the required template.
      5. View the new change request record created using the selected template by selecting Continue.
      Note:
      When you select an existing template, information in the predefined fields will be populated. Template fields are either read-only or mandatory depending on the template field policies configured while creating the template.

      For more information on change templates, see Create and propose a change template in Service Operations Workspace.
      Incident
      1. Open an incident.
      2. In the incident record form, select Create change request.
      Interaction
      1. Open an interaction.
      2. In the interaction record form, from the Create incident drop-down list, select Create change.
      Problem
      1. Open a problem.
      2. On the problem record page, from the Create problem task drop-down list, select Create change request.
    2. Select the change model that you want to create, and select Continue.

      You can filter and search for the change type.

      The following change types are available:
      Change model Description
      Normal Any service change that is not a pre-approved change or an emergency change.
      Standard A pre-authorized change that is low risk, relatively common, and follows a specified procedure or work instruction.
      Emergency An emergency change that bypasses group and peer review and approval, and goes straight to the authorization state for approval by the CAB approval group.
      DevOps or DevOps Simplified Change model used for DevOps change requests.

      To use the DevOps models, you must activate the DevOps Change Velocity application.

      For more information, see .

      Note:
      When you create a change request from an interaction, only pre-approved change types are available.
    3. In the Overview tab, fill in the fields.

      You must provide the initial details of the change in the Overview tab.

      Field Description
      Short description Brief description of the change.
      Description Detailed description of the change.
      Justification Reason for the planned change request, which helps approvers determine their decision.
    4. Select Save.

      The change request is created along with Scope and impact, Assignment, Schedule, Risk evaluation, and Change task sections.

    5. Provide the scope and impact information for the change.
      1. Select Add scope in Scope and impact section.
      2. On the form, fill in the fields.
        Table 1. Add scope form
        Field Description
        Configuration item Configuration item (CI) that the change applies to. You can associate any type of CI with a change request, including service offerings. It also provides detailed access to SLA and availability requirements.
        Service offering Consists of one or more service commitments that uniquely define the level of service in terms of availability, scope, pricing, and packaging options. Service offering enables you to receive different features and their levels of performance for a given service.
        Service The business service that you want to make available for the change request.
        Category The category of the change, for example, Hardware,  Network, Software, Other, DevOps, and so on.
        Note:
        The section to Add DevOps data (step 8 in this procedure) is enabled only when the category is selected as DevOps. For DevOps models, the category is automatically set to DevOps.
        Affected CIs Associate CIs with a single change request.
        Propose mass CI update Apply the same update to a set of CIs for a specific CI class.
        Propose single change Propose a change to one CI from your list of affected CIs.
        Refresh impact services When you refresh impacted services, the Impacted Services/CIs, Business Applications, and Service Offerings related lists get updated based on the affected CIs. The records in each of the related list are unique even though the impact can be from a single affected CI.
      3. Select Save.
    6. Assign the change request to relevant user or assignment group.
      1. Select Assign in the Assignment section.
      2. On the form, fill the fields.
        Field Description
        Assignment group Group assigned to the change.
        You can populate the Assignment group field automatically based on the support group available for the respective configuration item (CI). If the CI does not have any change group, then the field gets populated with the change group available for service offerings. The business rule Populate Assignment Group based on CI/SO triggers the functionality when an incident, problem, or change request is created or updated and when the Assignment group and the Assigned to field is empty. The following properties identify the field whose value populates the Assignment group field:
        • com.snc.change_request.ci_assignment_group.field_name: This change property identifies which CI field populates the Assignment group field.
        • com.snc.change_request.service_offering_assignment_group.field_name: This change property identifies which service offering field populates the Assignment group field.
        Note:
        The default value for the properties is support group for incident or problem and change group for change request respectively. The business rule Populate Assignment Group based on CI/SO is shipped as part of the development plugin ITSM CSDM Best Practice – Quebec plugin (com.snc.best_practice.itsm_csdm.quebec) and is available only for the new customers.
        Assigned to User assigned to the change request. If an assignment rule applies, the change is automatically assigned to the appropriate user or group.
        Work notes Information about how to resolve the change or steps taken to resolve it, if applicable. This note is for internal use. The work notes information is not visible to your customer.
      3. Select Save.
    7. Schedule the implementation for the change and view conflicts detected.
      Note:
      The conflict detection feature is unavailable if the Exclude from conflict detection check box in the Change Request form is selected. For more information, see .
      1. Select Set schedule.
      2. On the Schedule page, enter the planned start and end date.
      3. In the Conflict tab, the Schedule and conflicts section lists any detected conflicts.
        The Conflict last run field displays the date when the conflict detection was last run. You can view the details of the detected conflicts in the Related records tab.
        Note:
        When a conflict detection process is in progress, the Check conflicts button changes to View progress.

        The details of detected conflicts listed in the following table are displayed in the Conflict section.

        Field Description
        Change The current change request for which conflicts have been detected.
        Type The type of conflict detected.

        The following types of conflicts are displayed:

        • CI Already Scheduled
        • Parent CI Already Scheduled
        • Child CI Already Scheduled
        • Not in Maintenance Window
        • Parent Not In Maintenance Window
        • Child Not In Maintenance Window
        • Blackout
        Schedule The blackout or maintenance schedule the detected conflict is associated with.
        Conflicting Change The change that is in conflict with the current change request, if any.
        Affected CI The CI associated with the conflict detected.
        Impacted Services The services impacted by the detected conflict.
        Last checked Date when the conflict detection process was last run.
        For more information, see Conflict detection.
        Note:
        You can also run the conflict detection process manually by selecting Check conflicts.
      4. Optional: Reschedule your current change request if there is any conflict.
        1. Navigate to the Schedule page.
        2. Select the edit icon in the Current card.
        3. Select the new planned start and end dates.

        Alternatively, you can reschedule the implementation of the change to the next time and date there is no conflict by selecting Schedule in the Next conflict-free card.

        Change schedule Next conflict free card

    8. Optional: Select Add data in the DevOps data section to add DevOps data to the change request.
      Note:
      You must have the sn_devops.viewer role to add DevOps data to a change request or view DevOps data in an already created change record.
      1. Specify the following values on the Select associations step: Select DevOps data type and its associations step
        Table 2. Select associations
        Field Description
        Data type

        The type of data to associate with the change request.

        • Artifact version
        • Release version
        • Build number
        • Work item
        Data associations

        The specific data to associate with the change request. You can select multiple artifact versions, build numbers, and work items.

        If you select Build number as the Data type, then you must also specify the application name and corresponding pipelines and build numbers. If you select Work item as the Data type, then you can filter the list of work items available for selection by applications and plans.

        You can search for build numbers by the branch name as well.
      2. Select Next to open the Review data step. Review DevOps data step
      3. Navigate the tabs to verify that the associated data is mapped accurately.
        Update settings as needed.
        • Work Items
        • Commits
        • Pull Requests
        • Test Summaries
        • Artifact Versions
        • Software Quality Summaries
        • Security Scan Summaries
      4. Select Submit.
        Note:
        Once the commits are added in the DevOps data section, you can select View source corresponding to the Commits tile to view the source details of the commit like pipeline execution, branch, repository, and so on.
      5. Optional: To modify the data that is associated with the change request, select Edit DevOps data.
        1. Edit the data type and its associations from which DevOps data has been added in the Select associations step.
        2. Review the DevOps data that’ll be associated to or removed from this change request in Review data step.
        3. Select Submit.
    9. Select Risk evaluation to evaluate the risk for the change.

      The risk is calculated and is shown in Record information.

      The last evaluated risk value is displayed along with the timestamp.

    10. Select New in Change task section.
      For more information to create a change task, refer Create a change task in Service Operations Workspace.
    11. Associate the change with a product or service release.
      This option is available only if you have the Digital Product Release v2.4 installed. For more information, see Associating change requests with releases in Service Operations Workspace.
      1. Select Assign in the Related release card on the contextual side panel.
      2. In the Assigned to release dialog box, select the release you want to associate with the change request.
      3. If its a multi-product release, select the product within the release.
      4. Select the phase of the selected release to which you want to link the change request.
      5. Optional: Add work notes to provide context for the assignment.
      6. Select Assign.
    12. Optional: Import affected configuration items (CIs) from release phases to a change request.
      This option is available after the change request is associated with a release that has configuration items mapped to its release phases.
      1. Select Related records tab and select the Affected CIs option.
      2. Select Add CIs from release phase.
      3. Select Yes to confirm adding CIs from the release phase into the change request.
        The available CIs from the release phase of the associated release are added as affected CIs and listed.

        The import operation runs asynchronously. A notification is displayed when the operation completes. Refresh the list manually to see the newly added CIs.

    13. Select  Request Approval when the change request is ready to move to the next state.
      The state is moved forward based on the type of change request:
      • Assess state: Group level approval for a normal change request. Approval records are automatically generated based on the  Change approval policies. You can conduct peer and technical reviews of the proposed change.
      • Authorize state: Approval required by the business stakeholders, or by the Change Advisory Board.
      • Scheduled state: Pre-approved standard changes.
      Note:
      To mail the change record, select the more options icon (More options icon.) in the content frame and select Email. Both the user who requested the change and the user who is assigned to the change are automatically populated in the list of recipients.

      To view the calendar, select View Calendar in the title bar of the Change Request form.

    14. Select Save.