Skip to main content

Approach / 04 of 05

  1. 01 Discovery
  2. 02 Design & Build
  3. 03 Testing
  4. 04 Governance
  5. 05 Support

04

Keep work moving without losing accountability.

Henswick defines the ownership, approval boundaries, permissions, exceptions and control points that keep automated work understandable and accountable.

Control architecture

Control is part of the architecture, not something added afterward.

Testing shows how the workflow behaves. Control defines who it answers to, what it may act on, and where a person decides.

01 Event
Owned by The source-system owner defines which events may start the workflow.
02 Validation
On exception A record that fails a check stops here and routes to a named owner.
03 Automated action
Acts on Only the fields, records and systems the workflow is permitted to touch.
04 Human decision
Approval Where a person approves, rejects or releases before the path continues.
05 Downstream update
Limited to Named destinations only. Nothing outside the approved list is written to.
06 Confirmation
Records What changed, what or who caused it, and under which approval.
Control drawing 4.1 — Operating path with control points Teal: automated · Ink: human decision · Rust: exception

Authority register

Every automated action should have an owner and a boundary.

Operational responsibility is written down: who starts an action, what Henswick may do, where approval is required, and what is recorded.

Action Initiated by Allowed to act Approval required Record of action
A-01 Create or update a record
Initiated by A defined event in the source system
Allowed to act Yes — within the mapped fields
Approval required No
Record of action Action, source event and fields changed
A-02 Advance a workflow step
Initiated by A validated record that meets the step criteria
Allowed to act Yes — to the next permitted step only
Approval required At defined decision points
Record of action Step change, prior step and actor
A-03 Release a hold
Initiated by A named approver
Allowed to act No — manual only
Approval required Always
Record of action Approver, reason and time
A-04 Route an exception
Initiated by A failed check or a matched rule
Allowed to act Yes — to the assigned exception owner
Approval required No
Record of action Exception reference, owner and preserved state
A-05 Trigger an external action
Initiated by An approved workflow step
Allowed to act Yes — to named destinations only
Approval required Where the action cannot be undone
Record of action Destination, payload reference and outcome
A-06 Change a workflow rule
Initiated by A change request from the workflow owner
Allowed to act No — manual only
Approval required Always
Record of action Request, approver and revision
Authority register 4.2 — Illustrative workflow Teal rule: permitted to act · Rust rule: manual only

Decision boundary

Some decisions should remain deliberate.

Automation can gather, validate, route and prepare. Some decisions still belong to a person, and the workflow should stop and wait for them.

Control drawing 4.3 — Decision boundary on the operating path
01 Automated Event received and read.
02 Automated Record validated and routed.
03 Human decision A named person approves, rejects or releases.
04 Automated Approved action applied and synchronized.
05 Confirmed Outcome recorded against the decision.
Automation may Gather information · Validate · Route · Synchronize · Prepare the next action
A person decides Approve · Reject · Release · Override · Interpret an exception

We do not automate judgment just because technology allows us to.

Exception ownership

An exception without an owner becomes invisible work.

Every exception needs a detection point, a route, an owner, and a defined way back to the main workflow.

01 Exception detected A failed check, a stopped step or an out-of-range value halts the record.
02 State preserved The record, its history and its place in the workflow are held. Nothing downstream proceeds while it waits.
03 Owner assigned Routed by rule to a named owner, with the context needed to act.
04 Action or decision The owner corrects, approves, rejects or reassigns the record.
05 Resume or close The record returns to the main path, or closes with a recorded reason.

Carried with the exception

Source record

The rule or check that failed

Position in the workflow

Actions already taken

Assigned owner

Time raised

The owner receives the full context, not just a notification.

Exception record 4.4 — Ownership from detection to return Rust: held · Teal: control restored

Action history

If the workflow changes something, the change should be understandable.

Each action leaves a record of what changed, why, and what caused it, so the operation can follow what happened.

Action history — entry Illustrative
Event Approval recorded on a purchase request
Actor Automated step
System Finance system
Action Update request status
Previous state Pending review
New state Approved
Approval reference APR-0148, named approver
Exception reference None raised
Timestamp 14:32:07
What happened The request moved from pending review to approved.
Why An approval reference is attached to the change.
Who or what caused it A named approver’s decision, applied by an automated step inside its boundary.

Change control

The workflow should not change itself by accident.

Routing, approvals, rules and destinations change through a reviewed, approved and verified revision, not by drift.

01 Change request Raised by the workflow owner.
02 Review Impact on routing, approvals and records is assessed.
03 Approval The change authority signs off. Nothing proceeds without it.
04 Implement Applied as a new revision, not edited in place.
05 Verify Tested against the controls it touches.
06 Release Revision recorded. The previous one is retained.

Under change control

Routing

Approval logic

Added or removed destinations

Validation rules

Exception behavior

Permissions

Revision register 4.6 — Approval is the control point Ink: change authority

Control register

A control model the operation can actually follow.

The control register is the working document that turns automation logic into operating rules the team can follow.

Workflow control register Illustrative
Purchase request approval workflow One register per workflow, written in the operation’s own terms.
Ownership Who the workflow answers to.
01 · Workflow owner Finance operations lead
02 · Systems involved Request intake, finance system, notification channel
03 · Change authority Finance operations lead, with systems sign-off
Authority What it may do, and where a person decides.
04 · Permitted automated actions Create the request record, route it for approval, update its status, notify the requester
05 · Human approval points Requests above the approval threshold, and any change to supplier details
Exceptions What happens when it cannot proceed.
06 · Exception owner Accounts payable analyst on duty
07 · Fallback path Manual entry from the held request, using the preserved record
08 · Escalation path Finance operations lead, after the agreed response window
Evidence How the operation knows what happened.
09 · Record of action An action history entry for every step, with its approval reference
10 · Review point Scheduled with the workflow owner, and after any change to routing or approvals

Held by the operation. Reviewed whenever the workflow changes.

Next chapter / 05

  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
Ongoing Support

Keep the workflow healthy as systems, processes and operating conditions change.

Start here

Need automation without losing control of the operation?

Henswick can define the ownership, decision points and control boundaries around the workflow before it becomes part of day-to-day work.

Discuss your workflow