Change Management

Scope

The full change workflow in Beacon, including emergency changes and who can do what at each step.

After implementation begins, the Change record presents the actual-result decision inline. It starts unselected: explicitly choose successful, failed or rolled back after evaluating the work, then record that result. This remains separate from the subsequent PIR and its independent sign-off. Cancel hides the region while preserving the choice for that record; Review reopens it. Pending submission and loss of transition authority disable confirmation. Historical unknown outcomes remain unknown and are never filled from a later PIR. Emergency justification and PIR authoring/sign-off appear within the Change record, beside the next responsibility. Read the consequences and recorded evidence before pressing the explicit confirmation. Opening the record does not declare an emergency, record an outcome, or approve a PIR. Cancel hides the decision and preserves the draft while you remain on that record; its action button reopens it. Pending work disables confirmation and cancellation. If an action grant is removed, the draft remains readable but submission is disabled. After an uncertain PIR submission, read the current evidence before deciding whether another submission is appropriate; a recorded independent sign-off cannot be overwritten. Approved emergencies offer Implement without requiring a scheduled window, under the same attributable emergency policy.

When the title is untouched, selecting an affected CI supplies an editable title from its name and the chosen Change type. Any title you write, including an intentionally cleared title, takes precedence. This naming suggestion does not supply the technical plan, urgency justification, risk or outcome.

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.

Beacon suggests a risk band — you decide it

As soon as you name the configuration items this change touches, a Beacon suggests panel appears under the two risk dropdowns with a proposed impact and likelihood, and the reasoning behind it in plain sentences:

• how many CIs the change declares, and how many business services sit above them;

• tickets already open on the same kit;

• whether the proposed window lands in a change freeze, or clashes with another booked change;

• whether a change on this kit failed or was rolled back in the last 180 days;

• whether any of the CIs have nobody accountable for them.

There is no AI and no guesswork here — every line is a fact you can click through and check, and the panel shows the arithmetic (Impact +2, Likelihood +1) so nothing about the number is hidden.

Press “Use suggestion” to accept it. Nothing fills the dropdowns for you. Risk classification decides your CAB quorum and your PIR obligation, so the declaration stays yours; Beacon advises, records what it would have said, and shows the CAB if the two differ. Overriding is a normal, unpunished act — a higher declared band is caution, and you may well know something the CMDB does not.

No linked CIs, no suggestion. Every impact signal is read from the CI links, so a change with none gets an honest nudge to add them rather than a band invented from a title.

“Confidence” means coverage, not certainty. A confidence of 0.8 says Beacon had four of five evidence sources, not that it is 80% sure. Below your tenant’s floor (0.6 out of the box, set in Manage → Approvals) the panel still shows the same suggestion and the same evidence — collapsed, and captioned with what is missing. Linking more CIs, setting a window, and keeping the CMDB’s relationships current is what raises it.

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.

b. Revise a draft — and what happens after you submit

While a change is a draft, Edit (needs changes.author) revises its type, its plans, and its risk assessment. Impact and likelihood are re-assessed as a pair — Beacon stores only the resulting band and score, so one half on its own means nothing. Only the fields you actually change are sent, and the edit is recorded: an audit entry with the before and after of each field, and a timeline line naming what moved (“Implementation plan and Risk assessment revised (risk: medium → critical)”).

Two things Edit deliberately does not cover, because they each have one home:

• The maintenance window — use Set window / Reschedule, which run the freeze, notice-period and collision checks on every write.

• Title, description, priority and custom fields — edit those on the ticket itself.

Once the change is submitted, editing is closed. The Edit button is replaced by that sentence and the reason: what the CAB approved has to stay exactly what was submitted, or the approval record stops meaning anything. To revise a submitted, rejected, approved or scheduled change, put it back to draft (the withdraw/rework step), make the edit, and submit again — resubmitting opens a fresh CAB round from stage 1. A change that has already been implemented is historical and cannot be edited at all; raise a new change for further work.

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.

Your risk declaration is compared at submit. When you submit, Beacon recomputes the suggestion from the CIs, window and type as they now stand and stores both numbers on the change. If your band differs from its band, the change’s timeline records it in one line (“Risk declared Medium, below the platform’s suggested High — the CAB sees both”) and the approvers see a Risk overridden badge with the evidence. Withdrawing and resubmitting refreshes the comparison against the revised change.

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. The rejected record shows the CAB’s recorded reason and offers Return to draft and revise alongside the historical Close action. Returning to draft does not erase or reuse the rejected vote; resubmission opens a fresh CAB cycle.

• 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

b. Did it run in its window?

Beacon records when implementation actually started (when you press Implement) and when it actually finished (when you press Review), and compares both against the window the change was approved for. You do not enter anything; the two timestamps come from clicks you already make.

At Review the change is marked one of three ways, shown as a badge on the change, the register, the CAB inbox and the calendar:

Badge	What it means
Ran in window	Started at or after the booked start, and finished by the booked end.
Outside window	Started early, started after the window closed, or finished late.
No window booked	The change reached review having never had a maintenance window at all — so the freeze, notice and collision checks never ran against one.

There is no grace period. The window is the exact span the freeze and collision checks cleared, so starting an hour early counts as outside it too. If you need slack, book a wider window.

Outside window makes the retrospective mandatory. Beacon stamps a PIR deadline on the change and the existing close gate then holds it open until the review is filed. It also writes a plain-language timeline line saying what happened — “Implementation ran 02:10 – 04:41 against an approved window of 02:00 – 04:00 — finished 41 minutes late.” Beacon does not raise an incident for a window miss (there may have been no service impact); it makes you write down what happened.

A separate red Window passed badge appears on an approved or scheduled change whose booked window has come and gone with implementation never started. Re-scheduling clears it.

Change managers see both numbers on Manage → Compliance: Maintenance window adherence (target 95%) and Changes implemented with no window (target 0%). Emergency changes are excluded from both — they bypass scheduling by design — and changes implemented before Beacon started tracking this are excluded rather than guessed at.

Close with a PIR

When you move implementation into Review, choose the actual implementation result: Successful, Failed, or Rolled back. Beacon never infers success from reaching Review or Closed. Older integrations that use the published bodyless action can still end an ordinary implementation, but its work record says Implementation outcome was not recorded. A measured corrective Change instead asks the integration to record the result before it can leave implementation. A later PIR must match a recorded implementation result; a PIR added after an older unknown result remains separately labelled retrospective evidence.

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 (Manage → Change governance)	changes.governance.manage
Manage freeze windows	changes.freeze.manage

Recover an unconfirmed window update

Window fields display your browser’s local timezone and show the corresponding offset. Leaving an existing value unchanged preserves its exact stored instant, including seconds and a repeated daylight-saving hour. A new time in a missing clock interval is refused; a repeated local time requires an explicit offset choice. The end must be later than the start after conversion to instants.

While a window update is pending, the dialog prevents duplicate submission and dismissal. A refusal or lost response keeps the entered window visible. Select Read current change to see the current recorded window and status alongside your retained draft. This observation does not prove which attempt saved the window. After reviewing it, choose Use this reviewed window for another update to enable an explicit update; Beacon refuses it if the recorded window changes again before that update acquires its lock. A failed read retains the draft and recovery action. A terminal status cannot be updated.

Task-gate refusals show the blocking tasks in the shared dialog. Dismissing that explanation returns to the retained window draft. Closing and reopening the window dialog on the same record retains the requirement to read and review the current change; it does not submit another update automatically.

Recover a change creation whose response was lost

The create form keeps an immutable request and key in browser draft storage, scoped to your signed Portal identity and tenant, before sending it. If storage cannot be verified, it keeps your input and refuses to send. Older tenant-only drafts are not automatically assigned to the current Portal author.

After a lost response, use Pending creations to resume the draft and Check current record. A recorded change is shown with its current number, title and status; open that record instead of creating it again. A read showing no committed receipt is an observation, so retry remains an explicit action using the original key and body. Failed reads keep the uncertainty visible. Reloading or opening another tab does not automatically POST. A reference removed by another tab cannot silently turn an open editor into a new request.

If you need genuinely separate work while a previous request is unresolved, choose Keep pending and start a separate change and review the consequence confirmation. The prior reference stays discoverable and recoverable. Canceling that confirmation retains the original input. Malformed saved references are kept intact; their body cannot be resumed or sent, but their key can still be checked against the server. A deleted recorded change can be acknowledged; a retry never recreates it.

A confirmed create is cleared from the draft before CI linking finishes. The form displays the recorded change during that follow-up work. A CI-link failure does not mean the change failed to exist: open its Affected CIs panel, inspect which links are present, and complete the missing links there. An uncertain create recovered by readback likewise requires checking current CI links; readback does not automatically replay that separate operation.

Read a change and keep your place

Choose a change in the register to open its shareable number-based record URL. The header shows its full title, state, recorded accountable owner, organization, implementation window and next responsible role. On a phone, the record replaces the results surface; Back to queue restores the list and keyboard position. A direct-link read failure keeps the link and offers Retry rather than opening a different change. Changing Portal identity or permissions removes earlier record controls before accepting another response.

A group assignment is shown by its name. If a person or group is assigned but its name is unavailable, the record says so instead of calling the work unassigned. Names come from the stored assignment and current tenant-scoped display records; they do not certify a live Portal identity lookup.

Closed or rejected work labels its window as historical and explains that no implementation promise is active. Any later PIR evidence is identified as historical. An emergency CAB bypass is shown with its recorded justification; ordinary template quorum is not presented as an outstanding vote requirement. Independent emergency post-implementation review still governs closure.

When implementation has begun, use Submit PIR to record optional or required review evidence, or Amend unreviewed PIR evidence to correct it before an independent sign-off. The reviewer sees the recorded outcome, summary, lessons, author, and timestamp before signing. Reviewed evidence cannot be overwritten.

If a PIR action is unconfirmed, keep the retained draft and choose Read current PIR evidence. Compare the displayed current evidence with your draft, then explicitly accept that baseline before trying again. A changed current record is not proof the earlier request failed. If the current evidence is already reviewed, close the dialog and inspect that recorded sign-off; do not submit a replacement. Closing and reopening the dialog on the same mounted Change keeps your inputs and recovery requirement. Reloading the page does not preserve this editor draft, so read the current record again before starting new work.

The Calendar shows booked, intended, and historical windows separately. Every entry is a keyboard-operable link with the full title, status, and local time zone. On a phone, populated days become an agenda; on desktop, they remain a month grid. Use the day’s more button to reveal all entries rather than assuming the first three are the complete schedule. All overlapping freezes, including a freeze that starts partway through the day, appear with their bounds.

Opening a calendar entry retains the selected month and origin lens. Back to calendar returns to that month. Refresh calendar checks the same range; a failed refresh remains visible beside the previously read entries. Moving to another month never displays a late response as that month’s schedule.

The new Change form keeps affected-service search and its result area expanded while you complete the other fields. Search still needs a meaningful query and never substitutes failed or unauthorized lookup results for an empty success. A new PIR starts from the explicit implementation result already recorded on that same Change, when available. Review it and edit if necessary; existing PIR outcomes and your retained drafts take precedence, and submission remains an explicit decision bound to the displayed evidence version.

On settled Changes, the conflict card describes overlaps for the recorded planning window and offers no new scheduling instruction. Long conflict names and affected-service labels wrap within the record.