ITIL Changes
Route: /org/resolve/changes · Permission: View change requests and release status
Drafting, implementing and approving needs Draft, implement, and approve RFC changes.
1. What a change is
A change is a planned modification to something live, recorded before it happens and signed off by someone other than the person doing it.
The record exists to answer three questions after the fact: who approved this, what was the plan, and how do we undo it. That is why the drawer asks for an implementation plan and a rollback plan rather than just a title.
| Incident | Change | |
|---|---|---|
| Trigger | Something broke | We intend to modify something |
| Timing | Reactive, now | Planned, scheduled |
| Approval | None | CAB — a Change Advisory Board |
| Key artefact | The resolution | The rollback plan |
| Failure mode | Customer waits | Customer outage you caused |
The page's own summary: "Submit, approve, coordinate, and implement platform changes across their CAB lifecycle."
2. How a change spreads across the application
| Surface | Role |
|---|---|
| Problems | Where a change usually originates |
| Changes (this page) | Draft, risk-assess, approve |
| Releases | Group approved changes into a deployment |
| Ticket → ITIL & RMA tab | Bind a ticket to the change that caused or fixes it |
| Slack ChatOps | Approval cards, if configured |
| Executive analytics | Change Request Success Rate |
3. The screen
The count strip
Seven tiles, which double as the state vocabulary:
| Tile | Meaning |
|---|---|
| Total | Every change in the project |
| Pending CAB | Awaiting approval |
| Approved | Cleared, not yet implemented |
| Implemented | Done |
| Failed | Attempted, did not succeed |
| Rolled back | Reverted after implementation |
| Rejected | CAB declined it |
Toolbar
| Control | Behaviour |
|---|---|
| Board / List | Kanban columns, or a flat list |
| Search changes… | Matches title and description |
| Risk filter | ALL RISK · HIGH · MEDIUM · LOW |
| Swimlanes | Groups the board into horizontal risk lanes |
| + New Change Request | Opens the create drawer |
Columns tell you where each change is; swimlanes overlay how risky it is. A high-risk change sitting in Pending CAB stands out from a pile of low-risk ones. Open a change review with Swimlanes on.
The board
Each column shows its name, count and a collapse chevron. Empty columns read "Drop changes here". A card carries the title, a risk chip, a description extract, the record type and the date.
Dropping a change into Approved approves it. Treat the board as the record of record, not a planning sketch.
4. Creating a change — the drawer
| # | Field | Control | Required | Values / notes |
|---|---|---|---|---|
| 1 | Change Title | Text | ✅ | e.g. "Major upgrade PostgreSQL DB to v17" |
| 2 | Risk Level | Dropdown | Low Risk · Medium Risk · High Risk — drives the risk chip, filter and swimlanes | |
| — | Status | Dropdown | Pending CAB Approval · Approved · Rejected · Implemented · Failed · Rolled Back | |
| 3 | Implementation Steps | Textarea | "Provide explicit operational deployment roadmap…" | |
| 4 | Rollback / Contingency Plan | Textarea | "Provide detailed fallback instructions if implementation fails…" |
Nothing stops you saving a high-risk change with an empty rollback plan. The moment you need it, you need it under pressure, at speed, written by someone who is not available. Make a completed rollback plan a CAB entry condition — the tool will not enforce it for you.
It is not derived from anything. It drives the chip, the filter and the swimlane, so it is how a CAB decides what to scrutinise. A change mislabelled Low Risk is a change nobody looked at.
5. The lifecycle
Failed and Rolled back differ: Failed means it did not complete; Rolled back means it completed and was then reversed. Both count against change success rate, and the distinction is what tells you whether your problem is execution or planning.
6. Don't confuse this with…
| Screen | What it is |
|---|---|
| Changes (this page) | The approval and record of one modification |
| Releases | The shipping vehicle — groups approved changes |
| Problems | The reason a change exists |
| Resolution Queue | Has a CHANGE ticket type — a ticket, not a change record |
| Service Request Approvals | Also an approval flow, for catalog items — unrelated to CAB |
A change is one modification. A release is a scheduled shipment of several. Approving a change does not ship it; attaching it to a release and deploying that release does.
7. Troubleshooting
| Symptom | Cause |
|---|---|
| Board is empty | Wrong project |
| Cannot drag a card | You hold changes.view but not changes.manage |
| Everything is Medium Risk | Risk is a manual judgement and defaults are being accepted |
| Change approved but nothing shipped | Approval ≠ deployment. Attach it to a release |
| Slack approval card never arrived | ChatOps purpose must include approvals — Settings → ChatOps Integration |