Change approvals that arrive complete, with the evidence already attached

The readiness workflow is built in the workflow builder and starts from a webhook each time a change is submitted. It does four things in order.

• Reads the record. A ServiceNow block, or an API block for other tools, pulls the change, its linked tickets and attachments.
• Runs the checks. Rules flag missing fields: no rollback plan, no test evidence, no risk rating, a window inside a freeze period. Each rule returns a plain pass or flag, so the result is easy to read.
• Writes a summary. An Agent block reads the description and diffs and writes three lines: what changes, what could break, and what is missing. It does not set the risk rating; it can only point out that the stated rating looks low for the services touched.
• Routes or returns. A Condition block sends incomplete changes back to the requester with the list of gaps. Complete ones go to the right approver group, with the summary posted to their Slack or Teams channel.

How do you keep the requester and the approver separate?

Separation of duties is a rule, so treat it like one. The workflow compares the requester with the proposed approver and with everyone who committed to the change. If they overlap, the change is routed to a different approver group and the overlap is noted in the register.

The approval itself happens in the Human block, which pauses the run until a person decides. The decision, the approver’s name and the time are written to the change register in Tables, and the decision is written back to the change record so your ticketing tool stays the source of truth.

Workspace roles and permission groups decide who can edit the workflow. That matters: if the people whose changes are checked can rewrite the checks, the control is weaker than it looks. Because workflows run from a deployed version, an edit to the checks is itself a reviewed change.

What happens to emergency changes?

Emergency changes skip the queue by design, which is why they are where audits find gaps. Most policies allow them on the condition that they are approved retrospectively within a set period.

A Relay, an AI coworker with its own instructions and access, handles the follow-up. It runs each weekday morning on a schedule, queries the change register (read-only) and posts a note to the change manager listing emergency changes that still lack sign-off, who owns each one and what is missing. It runs at the Observe level: it can read and draft, and nothing else.

A Monitor covers the same risk from the other side. A rule monitor fires when one or more emergency changes are past the retrospective deadline, and alerts the change manager in the app or by email.

What does an auditor see afterwards?

For any change, a reviewer can follow one thread: the change record, the workflow run in Logs showing each block’s inputs and outputs, the checks that passed or flagged, the approver and the timestamp in the register. Changes to the agent setup itself appear in the workspace audit log.

If you are a financial entity in the EU, DORA’s ICT risk management requirements cover how changes to ICT systems are controlled. A setup like this does not make you compliant on its own, but it does produce the records those controls depend on. A dashboard on the register shows approval times, the emergency share and failed changes by team.

Where should a team start?

Start with the checks, not the summaries. Pick the three fields your approvers chase most, write them as rules, and run the workflow on new changes for two weeks without blocking anything. Compare its flags with what approvers sent back by hand. When the two agree, switch on routing, then add the Relay for emergency follow-up. For the access side of the same audit, see user access reviews; for collecting the evidence, see audit evidence collection.