ost approval automation starts with a reminder.
An item is submitted. A deadline approaches. The system sends an email or Slack notification asking someone to approve it.
That may reduce a little manual chasing, but it is not a complete business automation workflow.
A real approval workflow must know what is being approved, which version is current, who has authority, what state the request is in, what happens after the decision and how the system recovers when something fails.
Without those controls, automation simply sends reminders around the same unclear process.
TL;DR
A production approval workflow should include:
- explicit states and valid transitions
- persisted workflow context
- version-controlled approval packages
- role and authority checks
- deadline and escalation rules
- idempotent downstream actions
- complete audit history
- human checkpoints for consequential decisions
AI agents can prepare information, detect missing context and draft follow-ups. Deterministic workflow logic should still control what actions are allowed.
Start With the Approval Object
Before designing notifications, define what the system is actually tracking.
An approval should be more than a status field attached to a project.
A useful approval object may contain:
- approval ID
- project ID
- decision category
- current document version
- requesting user
- responsible approver
- submission timestamp
- required response date
- current state
- commercial or schedule impact
- related files
- comments and decision history
- downstream action to release
This gives the workflow a stable source of truth.
Consider a commercial interior project where a client must approve a flooring substitution. The supplier has proposed a different material because the original selection will miss the installation date.
The workflow is not merely asking, “Did the client approve?”
It must preserve the proposed material, specification, cost difference, lead-time impact, supporting files and authority of the person making the decision.
Model States, Not Buttons
Interfaces usually begin with buttons:
- Submit
- Approve
- Reject
- Request revision
But buttons are actions. The workflow needs states.
A material approval could move through:
draft → submitted → internal_review → client_approval_pending → approved → procurement_released → closed
Alternative transitions may include:
client_approval_pending → revision_requested
client_approval_pending → rejected
client_approval_pending → expired
Each transition should define:
- which actor can initiate it
- which information is required
- what validation must pass
- which event should be emitted
- which next actions become available
This prevents invalid operations, such as releasing procurement from an outdated or rejected approval.
Persist the Waiting State
Approvals are long-running workflows.
A person may respond in ten minutes, two days or two weeks. The workflow cannot rely on a request remaining active in memory while it waits.
The system must persist:
- its current state
- the approval package
- the last successful step
- outstanding deadlines
- the actor expected to respond
- pending downstream actions
When the approver responds, the workflow should resume from the recorded state rather than reconstructing the process from emails or logs.
This also matters when an application restarts, a worker crashes or an integration is temporarily unavailable.
A durable workflow should be able to continue without losing its business context.
Version the Decision Package
Approval without version control is dangerous.
A client may approve drawing version three while the project team has already circulated version four. A reminder may link to an older file. Procurement may receive an approval notification without knowing which specification was confirmed.
Every submission should create an immutable approval version.
A revised package should become a new version with its own:
- documents
- submission date
- decision status
- comments
- change summary
The system should never silently replace the content of an approval that has already been reviewed.
When a decision arrives, it must reference the exact version the person saw.
Treat Deadlines as Workflow Events
A due date should do more than change a row to red.
When a deadline is reached, the workflow should evaluate the consequence.
For example:
- Is procurement now blocked?
- Is the current price quotation about to expire?
- Is a construction activity dependent on this decision?
- Should the request move to another approver?
- Does the project manager need to intervene personally?
The next action should depend on business impact.
A low-risk decorative selection may justify another reminder. A long-lead material affecting site work may require immediate escalation.
For more context on the operational impact, see how client approval delays affect commercial projects.
Separate Commands From Events
A command asks the system to perform an action:
Approve request
An event records that something has happened:
ApprovalGranted
This distinction makes downstream automation easier to control.
When an approval is granted, separate consumers may:
- update the project register
- notify procurement
- prepare a purchase order
- update the programme
- inform the site team
- unlock a billing milestone
- archive the approved documents
The approval service should not need to synchronously complete every one of these actions before returning a response.
Instead, it can validate the command, commit the state transition and emit an event for the next processes.
Make Downstream Actions Idempotent
Events can be delivered more than once. Users can double-click buttons. Integrations can retry after a timeout.
A workflow must assume duplication is possible.
If ApprovalGranted is processed twice, the system should not create two purchase orders or send conflicting updates.
Every downstream action needs an idempotency rule, commonly based on:
- approval ID
- approval version
- event ID
- action type
The system should recognise that the action was already completed and safely ignore the duplicate.
Put Human Authority Inside the Workflow
Human-in-the-loop automation is not just an approval button.
The workflow should verify that the person:
- has authority for the decision
- is approving the current version
- can see the relevant cost and programme impact
- is acting before the request expires
- has provided a reason when rejecting or requesting revision
The approval interface should show enough context to support an informed decision.
A notification saying “Approve this request” creates a fast click, not necessarily a reliable approval.
Where AI Agents Fit
AI agents are useful around the workflow, not in place of its controls.
An agent can:
- summarise the approval package
- identify missing documents or fields
- compare the current version with the previous one
- draft a context-aware follow-up
- extract a decision from an email response
- classify comments as approval, rejection or revision
- flag conflicting information
- prepare an overdue-approval report
But the agent should not directly change the final business state simply because it interpreted a message as positive.
A deterministic validation layer should confirm the approver, version, permissions and required information before executing the transition.
The agent interprets unstructured information.
The workflow engine enforces business rules.
The Difference Between Automation and Control
Sending reminders is easy.
Building a dependable business process workflow automation system means accounting for waiting, revisions, permissions, retries, duplicates, deadlines, failures and downstream dependencies.
That architecture applies far beyond interior projects.
The same pattern works for:
- purchase requests
- invoice approvals
- contract reviews
- hiring decisions
- expense claims
- change requests
- content publishing
- production deployments
The domain changes. The fundamental workflow requirements do not.
For teams evaluating where this architecture could remove repeated coordination, the AI Agents Playbook maps approval, procurement, follow-up and project-reporting processes that can be automated without removing human judgment.
Top comments (0)