Enterprise Workflow Automation Patterns

Enterprise workflow automation looks more varied on the surface than it actually is. Across regulated industries — energy, banking, healthcare, government — the same six patterns keep recurring. Naming them, deciding which one applies, and committing to a clean implementation produces workflow estates that survive auditors. Skipping the discipline produces workflow estates that get audited.

This guide is the pattern catalogue we use when scoping a new workflow programme or when assessing one we did not build.

Pattern one — sequential approval chain

The most common shape: a request originates somewhere (citizen, employee, partner, system event), and it needs N approvals in order before the final state is reached. Examples: permit applications, expense approvals, employee onboarding requests, procurement requisitions.

Implemented well, this pattern has:

• Explicit stage names and ownership at each stage
• A defined SLA per stage with escalation triggers
• A clear "approved with conditions" path (rarely modelled, frequently needed)
• An audit record at each transition with the deciding actor, timestamp, and rationale field
• A defined "rejected" terminal state with downstream consequences (notification, rework path)

Implemented badly, this pattern is implemented as a series of email threads with manual handoffs and a spreadsheet for tracking. We have seen workflows in regulated environments running this way for years; the audit narrative is reconstructed from email forwards each time the regulator asks.

The architectural commitment is to model the chain in a workflow tool, expose its state to dashboards, and produce the audit trail as a first-class output rather than reconstructing it.

Pattern two — evidence collection workflow

Common in regulatory and compliance contexts: a process requires evidence to be assembled from multiple sources before a decision can be taken. Examples: licence renewals (financial records, inspection reports, certifications), regulatory filings (consolidated data from operational systems), audit responses (artefact collection from operational and engineering teams).

Evidence collection workflows are different from approval chains because the work is gathering, not approving. The pattern has:

• A defined checklist of evidence types and sources
• Assignments out to the people or systems holding the evidence, with reminders and escalations
• An evidence repository that the workflow attaches to as items arrive
• A completeness check that triggers the downstream decision step only when the checklist is satisfied
• A re-request pattern for evidence that arrives in inadequate quality

The most common failure mode is treating evidence collection as an approval chain. The chain pattern assumes someone is deciding at each step; the evidence pattern assumes someone is producing at each step. Mixing them produces workflows where reviewers receive partial evidence packages and either approve under-evidenced or push back, neither of which is the right behaviour.

Pattern three — escalation path

Every long-running workflow needs an escalation pattern. SLAs get breached. Approvers go on leave. Evidence requests don't come back. Senior intervention is occasionally required. The escalation pattern handles this without breaking the audit trail.

The implementations we see working:

• Time-based: at threshold X, notify the approver; at X+Y, escalate to their manager; at X+2Y, escalate to the workflow owner; at X+3Y, raise a senior intervention task.
• Exception-based: any explicit "I cannot decide" action by an approver triggers escalation to the next level, with the rationale captured.
• Out-of-band: the workflow owner can manually escalate any step at any time, with the action recorded.

The implementations that break: escalation handled informally through email or chat, with no system record. The escalation happened; the audit trail does not show it; the regulator asks how this case took eight months and the answer requires forensic email reconstruction.

Pattern four — exception handling

Distinct from escalation: an exception is when the workflow needs to deviate from the standard path. Examples: a permit application that requires a one-off committee review, an employee onboarding that needs special equipment provisioning, a procurement that requires a vendor exception waiver.

Modelled well, exception handling has:

• A defined entry point at any stage of the standard workflow into the exception path
• Named exception types (one-off committee, executive override, regulatory waiver, etc.)
• Different approval requirements for the exception itself (often more senior)
• A clear return to the standard workflow with the exception decision recorded
• A periodic review of exception frequency — if a particular exception is invoked monthly, it is not an exception, it is a missing standard path

The risk in exception handling is that it becomes the de facto standard. We have seen workflows where 30% of cases go through "exception handling" because the standard path doesn't fit common scenarios. That is a workflow design problem, not an exception problem.

Pattern five — parallel processing

Some workflows require multiple things to happen concurrently rather than sequentially. Examples: employee onboarding triggers IT provisioning, facilities setup, training assignment, and manager check-in simultaneously; regulatory filing requires legal review, finance review, and operational review in parallel before consolidation.

Parallel patterns require:

• A fan-out point where the parallel branches launch
• Independent SLAs on each branch
• Independent escalation behaviour per branch
• A fan-in point that waits for all branches (with a defined timeout behaviour)
• Visibility into per-branch state, not just overall workflow state

The common failure is modelling parallel work as nested sequential steps because the BPM tool felt easier that way. The result is a workflow that takes the maximum of the branch times multiplied by the branch count, instead of the maximum of the branch times. For a four-branch parallel workflow with one-week average per branch, this is the difference between one week elapsed and four weeks elapsed. Real organisational consequence.

Pattern six — audit-by-design

This is less a pattern and more a posture that the other five patterns require. Audit-by-design means: every workflow produces a complete narrative of what happened, with timestamps, actors, decisions, and supporting artefacts, queryable in a form an auditor can use without manual reconstruction.

What this requires:

• Every state transition writes a structured audit record
• Every actor decision captures the actor (not just the role), timestamp, and rationale
• Every artefact attached is versioned and immutable
• Every workflow instance has a stable identifier that follows it across systems
• The audit trail is queryable per workflow, per actor, per artefact, per time window

The estates we see with mature workflow practices treat the audit trail as a product — designed, maintained, owned by a named team. The estates with immature workflow practices treat audit as a side-effect that the BPM tool produces somehow.

For regulated industries, this is the single highest-stakes decision in workflow architecture. Audit failure during a regulator examination is not the kind of thing a remediation programme fixes — it is the kind of thing that causes operational disruption and reputational damage.

What the platform decision falls out from

Once the patterns and the audit posture are decided, the platform decision is much smaller. Most BPM platforms — Pega, IBM BAW, Camunda, OutSystems Process Engine — can support these patterns competently. The differentiation between them is in the operating tooling, the integration ecosystem, the licensing model, and the talent availability.

What does not work is choosing the platform first and assuming the patterns will sort themselves out. Workflow estates that drift do so because the patterns were never explicitly chosen; the implementation evolved per project; the audit story is whatever the implementation accidentally produced. The estates that hold up are the ones where the patterns were decided architecturally, documented, and enforced through review.

What we recommend

For a new workflow programme:

1. Catalogue the workflows in scope; classify each as approval-chain / evidence-collection / hybrid.
2. Define the escalation policy and exception model up front, before any modelling.
3. Define the audit record shape — every state transition emits this — before any modelling.
4. Then choose the platform.
5. Then start modelling specific workflows.

For an existing workflow estate that has drifted:

1. Run an audit of the actual workflows in production — not the documented ones, the actual ones.
2. Identify the audit gaps; close them as the first remediation.
3. Identify the workflows that have effectively become exception-driven; redesign their standard paths.
4. Bring escalation behaviour into the platform.

The pattern catalogue is small. The implementation discipline is what makes workflow estates work. We have not yet found a workflow problem that requires inventing a seventh pattern.