Change approvals that live in a meeting

The situation

Changes are raised, risk-assessed, approved by a board, scheduled into a window and implemented, with a rollback plan that has to exist before approval. Standard changes should not need the board at all. Today the request is a form, the assessment is a comment thread, the approval is a meeting, and the evidence an auditor wants is a minute somebody typed afterwards.

These are illustrative scenarios showing how the products are used, not customer case studies.

What gets modeled

The structure as it would actually be defined — sections that repeat are marked.

How it gets built

In the order somebody would actually do it. Each step names the capability it rests on, so it can be checked against the product pages.

1. 1

   Model the request, including the rollback

   Implementation and rollback are both repeating sections inside the plan, and rollback is required — so a change without one cannot be submitted rather than being waved through on the understanding that someone will write it later.

   What it uses: Nested repeating sections, with per-field rules including required

2. 2

   Read the service catalogue rather than a copy of it

   Affected services are choice fields reading live from the catalogue that owns them. A service added last week is available immediately, and a decommissioned one stops being selectable, without anyone editing a form.

   What it uses: Live option sources

3. 3

   Send standard changes down a short path

   A trigger starts the run on submission, with filters and conditional links routing pre-approved standard changes straight to scheduling. The board sees the changes that need a board, which is the only way a board keeps working.

   What it uses: Record triggers with filters, conditional links with an explicit default

4. 4

   Make the board a rule rather than a meeting

   Board approval is a human decision with a quorum or a weighted vote — a defined number of the standing members, or weights reflecting who must agree for a high-risk change. What was agreed is the decision record, not a minute typed afterwards.

   What it uses: Quorum and weighted-vote approval rules

5. 5

   Sign the high-risk ones properly

   Where the risk warrants it, approving means re-authenticating at that moment and choosing a reason from your own codes. What was recorded stays as recorded, and because the signatures chain, tampering with an earlier one is visible.

   What it uses: Re-authenticated, chained signatures with reason codes

6. 6

   Hold it until the window opens

   An approved change waits for its scheduled time rather than for somebody to remember. A step reads the permitted windows and the run parks until the window opens, with a deadline so it cannot wait indefinitely.

   What it uses: A step that reads the record mid-run, and steps that park with a deadline

7. 7

   Let it fail without losing the thread

   If implementation fails, the run does not restart from the beginning: the failed step is restarted in place, or the run is rewound to an earlier completed step with the later ones marked superseded. A run whose conditions match nothing stops and waits for an operator rather than guessing.

   What it uses: Restart a step in place, rewind to an earlier step, replay a run

8. 8

   Have the evidence already assembled

   The request, the risk assessment, who approved it under which rule, when it ran and what happened are attached to the record and its run history. The audit pack is a query rather than an exercise.

   What it uses: Record history alongside per-step run history

Numbers used above, and where they come from

Every figure on this site is counted from the product itself. Nothing here is a performance or customer claim, because there is no measurement to cite for one.