Change Management

Folder: change-management/ Colour: Teal #00897b

ITIL-aligned change request tracking with risk assessment, multi-member CAB workflow, a fully data-driven form builder (sections + fields, drag-and-drop), an activity timeline, and a calendar view.

The Table view supports saved views: save the columns, sort and filters under a name, share it with a team or everyone, and set one as the view the table opens with.

🛡️ Approvals and evidence (3.8.0): approvals recorded as rounds tied to exactly what was approved, an optional Enforce mode, full history of the long-text fields, an evidence export, approved standard-change templates, and read-only / approver-only access. Summary in Approvals and evidence below; the full design and its internals in Approvals and evidence - design (#180).

Change Lifecycle

Draft → Pending Approval → Approved → In Progress → Completed
                                                  ↘ Failed
                                       → Cancelled

All transitions logged in the audit trail. The status / priority / type / impact lookups themselves are admin-configurable — add a new type or rename a status without touching code.

Every status has a stage (3.8.0): Draft, Awaiting approval, Approved, Implementing, Done or Stopped, chosen in Settings → Statuses. The approval rules, the CAB vote, the Approvals page and Watchtower go by the stage, never the name, so renaming Approved to Authorised changes nothing. Closed follows the stage (Done and Stopped are closed). A status with no stage is marked in amber; Enforce cannot be switched on while one exists. The Draft, Awaiting approval and Approved stages always keep at least one active status, because the code moves changes into them.

Calendar View

Month / week / day views for visualising scheduled changes by their planned start/end window. Status-filterable (Draft, Pending Approval, Approved, In Progress, Completed, Failed, Cancelled). Click any event to open the change detail view.

Table View (table.php)

Full-screen Excel-style grid of all changes (ref, title, type, status, priority, risk, assignee, work dates and more) with column show/hide + drag-reorder (persisted per analyst), click-to-sort, search, per-column tickbox filters, and CSV export.

Inline editing — the low-risk list fields (type, priority, impact and assignee) are editable directly in the grid, each saved field-at-a-time via update_field.php (one column, one audit-trail entry). Status and the detailed fields (description, plans, risk, CAB) stay in the full change form, which you reach by clicking a row.

Approvals Page

Lists changes pending approval, filterable by:

• All — every pending change
• Assigned to me — changes I own
• Requested by me — changes I raised
• My CAB reviews — changes where I'm a CAB member with a pending vote

CAB (Change Advisory Board)

Multi-member approval workflow:

• Required vs Optional reviewers — Required reviewers must vote before the change can transition; Optional reviewers can vote but their approval isn't gating
• Configurable threshold: all required reviewers must approve, or majority
• Auto-status transitions on vote — once the threshold is reached, the change moves to the first Approved-stage status; a required Reject moves it to the rejection status chosen in Settings → Approvals (the first Draft-stage status by default)
• Votes belong to an approval round (3.8.0) — resubmitting starts a fresh vote, so an old Reject no longer sends the next submission straight back to Draft; every vote is kept in the round's history with whether it counted and the version it was cast against
• The named Approver decides (3.8.0) — on a change with an approver and no CAB, the approver gets Approve / Reject on the change
• Approval panel in the detail view: the current round, colour-coded vote cards per member, inline voting buttons for members with a pending vote, and the earlier rounds

Risk Assessment

5x5 colour-coded matrix:

• Likelihood (1–5) × Impact (1–5) → risk score (1–25) → risk level (Low / Medium / High / Critical)
• Auto-calculated as soon as both axes are set
• Threshold colours tuned to standard ITIL palettes

Post-Implementation Review

For changes in a Done-stage status (Completed, Failed), fields capture:

• What worked / what didn't
• Lessons learnt
• Actual vs planned duration

They are optional: nothing stops a change closing without them.

Activity Timeline

Single timeline in the detail view combining:

• Comments — inline commenting box, threaded
• Audit trail entries — every field change with who and when
• Text edits (3.8.0) — "edited the Test plan - View", opening the full text history
• Attachments added and removed, deleted comments and evidence exports (3.8.0)

Both render chronologically so the change's whole story sits in one column.

Approvals and evidence

Built in 3.8.0 from #180. Every rule is a setting whose default is the behaviour before 3.8.0; the record-keeping starts on upgrade whatever the settings.

• Approval rounds — submitting a change opens a round holding a snapshot of exactly what was submitted (long text by revision). It closes as approved, rejected, withdrawn or superseded. A hand-set Approved is recorded as a set by hand round. Changes past submission on upgrade get a one-time before approval records round.
• Votes against the version on screen — a vote or approver decision carries the round and content version its page was drawn with; one from an out-of-date page is recorded and marked, or refused (always in Enforce).
• Record or Enforce (Settings → Approvals) — Enforce refuses a move into Approved, Implementing or Done without a current approval on every path, including the REST API; refuses a submission nobody independent could decide; fixes the approvers once submitted; does not count the change's own people's votes (administrators included); and sends a materially edited change back for approval.
• Emergency — a type set to Emergency - approve afterwards may go ahead with its round open; Watchtower shows it until decided.
• Administrator override — optional, with a written reason, recorded as such.
• Text history — every saved version of the eight long-text fields, in full, with a viewer that compares any two. Pre-upgrade text is "as found when history began".
• Export evidence — the change's share menu: a printable pack of the change, every round and vote, every text version, the audit trail, comments (deleted ones included) and attachments with sha256.
• Cancel instead of Delete — where Settings (and always Enforce) keep submitted changes, Delete becomes Cancel.
• Standard changes from approved templates (Settings → Templates) — see Part 1 §8.
• Read only access (System → Modules) and Choose approvers (Roles) — see Module Access Control and Roles & Permissions.

Configurable Form Layout

The change form itself is data-driven — sections and field placement are managed under Settings → Form fields, not hardcoded.

Sections

• Add / rename / reorder / delete sections — each section is its own card with a drag handle. Rename inline by clicking the title. Delete prompts you to pick a destination section for that section's fields so nothing is orphaned.
• Drag fields between sections — each field is a row inside its section card with its own drag handle and a Visible toggle. Drop it into another section to re-home it; the change form picks up the new placement on next render.
• Auto-save — every change (add section, rename, reorder, toggle visibility, move a field) debounces at 350ms and saves the whole layout in one transaction. No Save button to forget.
• Unplaced fields — catalogue keys that aren't in any section yet (e.g. after a future field-catalogue addition) surface as their own row under the section list so an admin can drag them into place.
• Empty sections auto-hide on the change form, so toggling every field off in a section hides the section heading too.

Field width pairing

Each field in the catalogue has a fixed width: half or full. Dropdowns, datetime pickers and short text fields are half; textareas, composite widgets (CAB, risk-scoring) and headline fields like Title are full. The change form is a flex-wrap row per section, so:

• Two half fields next to each other in display order pair on one row
• A half field whose neighbour is full (or which trails at the end of a section) stretches back to full width — no awkward whitespace
• Reordering in settings controls the pairing — put two halves adjacent to pair them, or drop a full between two halves to break them apart

The field's width is a property of the field, not the slot, so moving a field to a different section keeps its width.

Settings

Tabs:

• Form fields — configurable sections + field placement (see above)
• Statuses — workflow states the change can be in, each with its stage; Closed follows the stage; exactly one is the default for new changes
• Priorities — priority bands shown on change records
• Types — categories of change request (typically Standard, Normal, Emergency), each with How it is approved: Needs review or Emergency - approve afterwards. A type never pre-approves a change; only an approved template does
• Impacts — impact bands describing how widely a change affects the business; combines with priority to drive risk scoring
• Templates (3.8.0, changes.templates) — standard-change templates and their versions; visible to template approvers too
• Approvals (3.8.0, changes.approvals, sensitive) — the approval rules

Each of the four lookup tabs (Statuses / Priorities / Types / Impacts) uses the canonical sentence-case settings layout with a single-word Add button and pencil / trash row icons.

Help

Interactive guide at change-management/help.php covering change types, lifecycle, recording changes, CAB review, risk assessment, post-implementation review, and (3.8.0) approvals and evidence.

Key Tables

Table	Purpose
changes	Core change record
change_statuses / change_priorities / change_types / change_impacts	Configurable lookups (Name, Colour, IsDefault, IsActive, DisplayOrder; statuses also carry is_closed)
change_field_sections	Configurable form sections (id, name, display_order)
change_field_layout	Per-field placement (field_key, section_id, display_order, is_visible) — unique on field_key, FK to change_field_sections with ON DELETE CASCADE
change_cab_members	CAB reviewer assignments per change, and each member's vote in the current round
change_approvals	Approval rounds (3.8.0) - route, state, snapshot, content fingerprint, who decided; ON DELETE RESTRICT from changes
change_approval_votes	Every vote ever cast (3.8.0) - counted or not, version it was cast against
change_text_revisions	Every saved version of the long-text fields, and deleted comments (3.8.0)
change_templates / change_template_versions / change_template_teams	Standard-change templates: the working draft, its approved versions, who may use it (3.8.0)
change_audit	Field-level change history
change_comments	Threaded comments on the activity timeline
change_attachments	File attachments