Skip to main content

​
What This Does

This guide walks through the full change request process, including the information reviewers and approvers typically need.

​
Before You Begin

Have these details ready:
  • the purpose of the change
  • the systems or services affected
  • the implementation plan
  • the rollback plan
  • the expected impact window
  • any testing or validation steps
  • the requestor, coordinator, approvers, assignee, and responsible team if your process uses them

​
Steps

  1. Open ITSM.
  2. Select Create New.
  3. Choose Change Request.
  4. Enter a title that explains the change clearly.
    • Good example: Upgrade production API gateway to version 3.4
  5. Add a description that explains:
    • what is changing
    • why it is needed
    • who is affected
  6. Choose the correct category.
  7. Set the priority based on urgency and business need.
  8. Add risk and impact details if those fields are present.
  9. Select the related application, module, feature, environment, or release.
  10. Select the requestor and coordinator if your process requires them.
  11. Add one or more approvers if approval is required.
  12. Select the responsible team and assignee if known.
  13. Enter the implementation plan.
  14. Enter the rollback plan.
  15. Add validation or post-deployment checks.
  16. Save the change request.

​
Verify the Result

  1. Open the change request detail page.
  2. Confirm the title, priority, and linked records are correct.
  3. Confirm approval and status workflow fields are visible.
  4. Confirm approvers are listed correctly if the change has multiple approvers.
  5. Add comments or attachments if supporting evidence is needed.

​
Who Can See the Change in List View

A change request should appear in list view when the current user is any of the following:
  • Requestor
  • Coordinator
  • Approver
  • Assignee
  • Creator
  • Member of the team assigned to the change
If a change request is missing from the list, check the active organization, selected team, filters, and whether the user has one of the relationships above.

​
What Happens Next

A change request usually moves through:
  1. review
  2. approval
  3. scheduling
  4. implementation
  5. validation
  6. closure

​
Tips

  • Write the title so another team can understand the change quickly.
  • Use the description for business context, not just technical notes.
  • A weak rollback plan slows approvals.
  • Keep approvers current. Approvers are a multi-user field and should represent the real decision makers for the change.