Authorize a change and close its review
Choose the approval path, satisfy the schedule and implementation gates, and verify the post-implementation review.
Demo baseline · November 13, 2026Roles and prerequisites
Use the Agent workspace for changes. The requester or owner provides the implementation, validation, and backout details. Eligible CI owners, business-process owners, CAB or E-CAB members decide the applicable stages. Post-implementation review has a separate approval gate. Confirm the affected CIs have the necessary owners before submitting.
| Change path | Before authorization | Expected approval |
|---|---|---|
| Normal | Valid affected CIs and a scheduled CAB meeting. | CI Owner, Business Process Owner, then CAB. |
| Emergency | Affected CI owner and an active E-CAB group with members. | CI Owner, then E-CAB. |
| Standard using an approved template | Active unexpired template for the selected path. | The approved template supplies authorization. |
| Standard template creation or other approval path | Select the proper model and applicable owners and governance board. | Follow the requested stage and verify the resulting template where applicable. |
Implement and review
- From Changes, open Risk & approval. Complete the risk questionnaire and check conflicts, blackout periods, time zone, and CAB schedule. For a normal change, the server can move the planned start forward to meet the five-business-day lead time or place it after the selected CAB meeting. Reopen the saved change and verify both dates. Move to Authorize, then verify the first stage and the eligible decision makers.
- Check Approval stage after each decision. An eligible user for the next stage decides after the previous stage is complete. Recheck the schedule before moving to Scheduled or Implement. A conflicting schedule blocks both states.
- In Implementation, execute the approved plan. Mark every implementation task complete or skipped and record actual results and the post-implementation validation. Enter Review from Implement.
- Verify the review was requested and obtain the approved post-implementation review before closing. Check the linked problem's corrective action if the change came from a problem.
- For a problem in Root cause analysis, the request to advance to Fix in progress first opens an approval against the selected CI approval group. Check the decision and the linked change before progressing remediation.
Recover a blocked change
A missing board, owner, CAB meeting, or active template is a prerequisite failure. Fix the specific record or pick the correct change type. Resolve schedule conflicts and resubmit where the current approval needs review. If Review or Closed is blocked, inspect implementation tasks, confirmation, validation, and the review decision.
A normal change without a CAB meeting returns HTTP 400 with Normal changes require a scheduled CAB meeting before authorization. Reopen the change and verify its state did not advance. Select an active scheduled CAB meeting of type CAB, save, and compare the persisted start and end dates. Retry Authorize and verify the expected approval stage. If the response is a generic 500, capture the error ID and request time and check the serving revision before retrying.