Change Management

Scope

Change governance works when it is fast enough that nobody routes around it. This guide keeps the end-to-end change workflow and removes private route detail.

This is the operator how-to for running a change end to end in Beacon: authoring it, clearing governance, getting CAB approval, scheduling it around freeze windows, implementing it, and closing it with a post-implementation review (PIR). Change work lives in the Changes workspace (the relevant workflow) for L3/engineering and the CAB surfaces in the Administration console (the relevant workflow) and the Changes workspace for managers.

Beacon ships change control ready to use: a fresh tenant is seeded with governance templates (standard / normal / high-risk-CAB / emergency), an example year-end freeze window, and a CAB assignment group — you tune these rather than build them from scratch (the relevant workflow, and governance defaults).

Getting around

The Changes workspace header carries the workspace switcher (the same one as the Service Desk), so you can hop to any shell or shared workspace you have permission for. When you arrive from a persona shell (the L3 Engineering “Change authoring” card, or a Desk ⌘K command), the header also shows ← Back to L3 Engineering (or Service Desk / L2 Operations) returning you to exactly where you came from; the origin survives tab switches inside the workspace. Selecting a change shows a small breadcrumb (Change Management → CHG-xxxx) above the detail header.

The change lifecycle

Every transition is deterministic; illegal moves are rejected. Standard, normal, and emergency changes follow the same spine but hit different gates.

Author the change

In the Changes workspace choose New change (needs changes.author). Provide:

• Title and description of what is changing and why.

• Change type: standard (pre-approved, low-friction), normal (the default, full governance), or emergency (expedited — see below).

• Implementation plan and backout plan. Governance usually requires both; write the backout plan as if you will need it at 2am.

• Schedule window (optional at authoring, required before scheduling).

• Risk: pick an impact (1–5) and likelihood (1–5). Beacon multiplies them into a 1–25 score and shows the band (low / medium / high / critical). You do not set the band directly — higher scores automatically pull in stricter governance and a larger CAB quorum.

The change starts in draft. You can keep editing it there.

Your typing is never lost. The New change form autosaves to your browser (per tenant) as you type. If you navigate away, reload, or get pulled into an incident mid-authoring, reopening New change offers Resume draft / Discard — nothing is silently restored, and the draft is cleared automatically once the change is created.

The focused change lives in the URL — the relevant workflow (by shareable number, same convention as the desk’s ?ticket=; legacy internal-id links normalize themselves) — so any change can be bookmarked or pasted into chat. The New change slide-over takes a history entry: browser back closes it instead of leaving the workspace.

Submit — the governance gate

Submit moves draft → submitted (needs changes.transition). Before it succeeds, Beacon evaluates every active governance template that matches the change’s type and risk band. If a requirement is unmet the submit is blocked and the response lists exactly what is missing — typically a required implementation plan and/or backout plan. Add what’s missing and submit again.

Submitting also opens the CAB approval request; its required number of approvers (the quorum) comes from the matching governance template.

CAB approval

Managers/change managers work the CAB inbox (needs changes.approve; reachable from the Changes workspace and the ⌘K command palette as “Approve changes — CAB inbox”). Each pending change shows its risk band, plans, schedule, and approval progress (n/quorum).

• Approve: once the quorum of distinct approvers approve, the change advances to approved. The approve step also enforces the governance notice hours — if the scheduled start is sooner than the template’s minimum lead time, approval is blocked until you push the window out.

• Sequential stages: a governance template may define approval stages (e.g. peer review → CAB). The inbox and change detail then show “Stage n of m” next to the per-stage progress; approving a mid-sequence stage keeps the change in submitted and starts the next stage, and only the final stage’s quorum (plus the notice/freeze checks) moves it to approved. One decision per approver per stage.

• Reject: the first rejection — at any stage — sends the change to rejected; from there it can go back to draft for rework and re-submission.

• Why this change exists: a change raised from a problem’s RCA shows a Raised from problem card on the change detail — the problem’s number, status, known-error flag and root-cause summary, with a link straight to the problem. You should not have to leave the approval screen to find out what a remediation is remediating.

b. Setting the window before approval

Approval enforces the governance notice hours against the change’s scheduled start, so a change with no window cannot be approved. You do not have to send it back to draft or re-create it: Set window is available on a change in draft or submitted and writes the window in place without moving the change — the CAB request stays open and you can approve immediately after. The same action on a scheduled change re-schedules it.

The freeze and collision checks run on every window write, so moving a window into a frozen period is refused there and then rather than at the next transition. A draft or submitted change with no window carries a warning on its Schedule card saying so.

Schedule around freezes

Schedule moves approved → scheduled and sets the implementation window. The change calendar (Changes workspace, and reachable from ⌘K as “Open change calendar”) shows scheduled changes alongside the active freeze bands.

Freeze windows (managed in the relevant workflow) block approval and implementation during sensitive periods. If your window overlaps a freeze, either move the window or, if it genuinely cannot wait, run it as an emergency change (which bypasses freezes — see below). Emergency changes are the only type that crosses a freeze.

b. Collisions — is this kit already booked?

A freeze answers “is this period closed?”. It cannot tell you that another team CI-collision detection is for.

Tell Beacon what the change touches. The Affected CIs panel on the change (and the same field in the New change dialog) links the change to configuration items. A change with no linked CIs cannot collide with anything, so this is the one step that makes the rest work. Each linked CI opens straight to its CMDB record — click through to check its type, status, or other links before deciding whether a flagged collision is real.

What counts as a collision. Another change whose window overlaps yours and which touches either:

• the same CI — shown without a badge, or
• a related CI — badged related · N hops. Beacon follows the CMDB’s existing relationships, so a window on a host conflicts with a deployment of the application running on it even though the two changes name different CIs. The walk goes two hops (host → application → business service); a note appears if it had to stop early, so you know the list may be incomplete.

Back-to-back windows do not collide — a change ending at 02:00 and one starting at 02:00 are sequenced, not overlapping.

What happens then depends on the governance template that matches your change (the relevant workflow, field Collision policy):

Policy	What you see
Warn (default)	An amber notice listing the conflicts. You can still schedule and approve — the conflict is recorded on the change’s timeline so the decision is on the record.
Block	A red notice, and Schedule is unavailable until the windows no longer overlap. Approval is refused too.
Off	Collisions are not checked for changes this template matches.

The New change dialog and the Schedule dialog both show this while you are still typing the window, so a conflict is something you fix cheaply rather than discover as a refusal after filling in the form.

Emergency changes are never blocked by a collision — same rule as freezes. You are still told about it.

Implement and review

re-checked here against now (not just the scheduled start), so a change that slipped into a freeze is stopped.

• Do the work, then Review moves implementing → review.
• If a linked problem/RCA drove this change, moving to implementing automatically advances that problem to its implementing state — the RCA tracks its own fix

Close with a PIR

Close moves review → closed. For most changes you record the post-implementation review here: the outcome (successful, failed, or rolled_back), a summary, and lessons learned. For any change carrying a PIR deadline (all emergencies do), close is blocked until the PIR is recorded — so the review is never skipped.

Emergency changes

Set the change type to emergency when production is on fire and normal CAB timing is not survivable. On submit an emergency change auto-approves (submitted → approved) without a CAB round and bypasses the freeze check at both approve and implement. In exchange, Beacon sets a mandatory PIR deadline 72 hours out and will not let you close the change until that PIR is filed. The submit governance gate still applies — the seeded emergency template requires a backout plan, so even a fire drill keeps a rollback path.

Quick reference — who can do what

Action	Permission
Author / edit a change	changes.author
Submit / schedule / implement / review / close	changes.transition
Approve / reject at CAB	changes.approve
Manage governance templates	changes.governance.manage
Manage freeze windows	changes.freeze.manage