Changes
A change request tracks any planned change to a service or piece of infrastructure, from the initial request through approval, scheduling, implementation, and review.
Change types
Section titled “Change types”The Type field drives the approval path:
- Standard change — pre-authorized, low-risk, repeatable work created from an approved template. Skips Assess and Authorize entirely and goes straight to Scheduled.
- Normal change — the full lifecycle: assessed, then authorized by the Change Advisory Board (CAB) or the change manager.
- Emergency change — expedited, for fixing or preventing a major incident or critical security issue. Approved by the Emergency CAB (ECAB), a smaller on-call subset of the board; approval may happen after the fact. Still requires a review (PIR) after implementation.
States and approval gates
Section titled “States and approval gates”| State | What it means | Typical next action |
|---|---|---|
| New | The request has been raised and is being drafted — short description, type, affected CI/service, justification. | Request Approval (Normal/Emergency), or jump straight to Scheduled (Standard) |
| Assess | Risk and impact are being evaluated, plans drafted (implementation, backout, test), and the change assigned. Normal changes only — Standard skips this. | Request Approval |
| Authorize | Awaiting approval — CAB/change-manager for Normal, ECAB for Emergency. Standard changes are auto-approved by their template. | Approve (moves to Scheduled) or Reject |
| Scheduled | Approved and given a planned start/end window. Conflict detection runs against affected CIs and blackout/maintenance windows. No work happens yet. | Implement, once the planned start date arrives |
| Implement | The implementer is executing the change plan and its change tasks. The backout plan is invoked if implementation fails. | Review |
| Review | Post-implementation review (PIR) — assessed for success against the plan. | Close |
| Closed | Terminal. A close code (Successful / Successful with issues / Unsuccessful) and close notes are recorded. | — |
| Canceled | Terminal. Withdrawn before completion — rejected at CAB, superseded, or no longer needed. Can happen from any pre-close state. | — |
Closing is gated: you can’t reach Closed without a valid close code and close notes.
Transitions at a glance
Section titled “Transitions at a glance”- Assess (New → Assess), or Schedule (Standard) (New → Scheduled) for pre-approved template changes.
- Request Approval (Assess → Authorize).
- Approve (Authorize → Scheduled) or Reject / Request more info (Authorize → Assess) or an outright Reject (Authorize → Canceled).
- Implement (Scheduled → Implement) once the conflict check is clear.
- Review (Implement → Review).
- Close (Review → Closed).
- Cancel Change — available from New, Assess, Scheduled, or Implement.
- Revert to New — an administrative reset, available from Assess, Authorize, or Scheduled.
The CAB Workbench
Section titled “The CAB Workbench”The CAB Workbench is where a Change Advisory Board reviews the agenda of changes awaiting authorization. Each row shows the change’s key risk signals — type, risk, impact, planned window, and conflict status — with inline Approve and Reject buttons that drive the real state change (Approve moves a change to Scheduled; Reject moves it to Canceled). Already-decided changes stay visible in a read-only Decided section so the board keeps context on what it already ruled on.
The Change Calendar
Section titled “The Change Calendar”The Change Calendar shows planned change windows on a month grid, so you can see what’s scheduled to happen and when before you approve or schedule anything new. Schedules lists the maintenance windows changes can be planned against.
Change tasks
Section titled “Change tasks”The Change tasks tab decomposes implementation into individual pieces of work — planning, implementation, testing, and review — each with its own assignee and planned start/end.
Conflict awareness
Section titled “Conflict awareness”Conflict status (Not run / Conflict / No conflict) is computed against the change’s planned window: it flags an overlapping change window on the same configuration item or service, or a collision with a blackout/freeze window, and reports whether the planned window falls outside an approved maintenance schedule. This feeds both the Schedule step and the Change Calendar.