Approvals in automated flows

Automation is good at the boring part. But some moments in a process belong to a person: the clerk who decides an agenda is ready to go public, the finance manager who releases a payment file, the department head who signs off on a data correction.

The common answer is to stop automating at that point. Someone gets an email, logs into a second system, and does the last step by hand. That works, but it splits the process in two, and the hand-done half has no log.

What an approval step should do

An approval in a flow is simple to describe:

• The flow runs as usual until it reaches the approval step.
• It pauses and tells the approver what is waiting, and why.
• The approver approves or rejects.
• On approval, the flow carries on from that point. On rejection, it stops.

The hard part: what the flow holds while it waits

A pause can last minutes or days. The question that matters is what the flow keeps while it's waiting.

The easy design keeps the records: park a copy of everything that reached the approval step, then send that copy on approval. That's the wrong design for local government, for two reasons:

• It creates a copy of resident data that sits in a queue, possibly for days. That copy has to be secured, retained, and potentially produced under a public-records request.
• The copy goes stale. If staff corrected an agenda item on Tuesday and the approval comes Wednesday, the parked copy is Monday's version. Approving it publishes the wrong thing.

Hold IDs, re-read on approval

The better design holds only the record IDs. When the approver says yes, the flow reads those records again from the source system, by ID, and continues with the current version.

This fixes both problems at once. Nothing but identifiers is stored while the flow waits. And what gets delivered is what the system of record says now, not what it said when the flow paused.

Good places for an approval

• Publishing agendas to the website or archive, after the clerk's final check.
• Releasing payment or refund files to the bank's SFTP folder.
• Bulk corrections, such as a reverse sync that will update thousands of rows.
• Public notices, such as posting an alert to the city website.
• Anything a policy says needs a second set of eyes.

Bad places for an approval

Approvals cost attention. If every run waits for a click, people start clicking without reading. Avoid them for:

• High-volume, low-risk flows, such as copying 311 requests into the city database every 15 minutes.
• Checks a rule can do better. "Account number must not be blank" is a rule, not a judgment call. Use a rules step with a Valid and an Invalid output, and send the failures to a person instead.

A useful test: if the approver would need to look at something a machine can't judge, it's an approval. If not, it's a rule.

What the approver should see

An approval request should be specific enough to act on without opening three other systems:

• Which flow, and which run.
• How many records are waiting, and which IDs.
• What will happen on approval: "Publish 4 agendas to the city website".
• A link to preview the records, read fresh from the source.

Who should approve

Name a role, not a person, where you can. "The deputy clerk on duty" survives vacations; "Maria" doesn't. And decide in advance what happens if nobody responds: a reminder after a day, and a rejection after a week, is better than a run that waits forever.

Approvals and the audit trail

Every approval or rejection should land in the activity log with who, when and which run. That turns "I think Maria approved it" into a record you can point to.

In SentraBridge

In SentraBridge, a flow can pause for a person to approve. While it waits, it holds record IDs only, and on approval it re-reads those records from the source before continuing, in keeping with its pass-through rule. Paused and approved runs sit alongside the rest of the flow's monitoring. See approvals for more.