Workflow Automation Architecture

The workflow programmes we have rescued have one thing in common. The architecture was not wrong; the architecture was never really decided. Each workflow was built against the most expedient pattern at the time. Three years later, the estate was a collection of one-off implementations that happened to share a platform.

The estates that mature into platforms are the ones where a small set of architectural choices were made early, written down, and defended. This piece is the catalogue of those choices.

The runtime placement decision

The first decision is where workflow logic actually lives. Three placements compete:

In the BPM platform. The BPM engine owns the process model, the task assignment logic, the SLA tracking, the state transitions. Other systems (integration platform, identity provider, document store) are services the BPM platform consumes.

In application code. A custom-built application owns the workflow logic — the state machine, the persistence, the task UI, the SLA timers. The integration platform is invoked from the application. The BPM platform is absent.

Distributed across applications. Each application owns its part of the workflow. Handoffs between stages happen through events, files, or API calls. No single system has the end-to-end view.

The third option is the one that fails most often. It looks decentralised and modern; it produces estates where nobody can answer "where is this case now" without forensic reconstruction across multiple systems. We have rescued several distributed-workflow estates by consolidating into option one or two.

Between the first two options, the choice is workload-shaped. BPM platforms excel when the workflow is the product — the audit trail, the SLA dashboard, the human task UI, and the state visibility are first-class. Custom application code wins when the workflow is incidental — most of the value is in the application, and the workflow is a small stateful component within it.

The architectural commitment is to make this decision consciously and document it. The estates that drift are the ones where the choice was implicit.

The orchestration boundary

If the BPM platform owns the workflow logic, the next decision is where the integration boundary sits. Two patterns compete:

BPM as orchestrator. The BPM platform invokes integration services directly to interact with systems of record. Each task in the workflow that needs to touch a downstream system calls an integration service synchronously. The BPM platform is the orchestrator; the integration platform is the transport.

BPM behind an integration facade. The BPM platform invokes a small set of facade APIs published by the integration platform. The facade APIs encapsulate the integration logic; the BPM platform sees clean service contracts, not direct system interactions.

The facade pattern is operationally cleaner. When the underlying system changes (new ERP, new CRM, new partner system), the facade absorbs the change; the BPM platform's workflow model is unaffected. The orchestrator-direct pattern is faster to build initially but couples the BPM platform to every system change.

For workflow estates that will outlive several system migrations — and most do — the facade pattern repays its upfront cost many times.

State persistence and recoverability

Workflows run for days, weeks, months. State persistence is non-negotiable.

The patterns that work:

• Database-backed state with the BPM platform as the system of record for workflow state. The platform's persistence layer is the source of truth; nobody else writes to it directly.
• Event-sourced state where each state transition is an event in an append-only log; the current state is computed by replaying events. More complex, but produces unambiguous audit trail by design.
• Hybrid — current state in a database for fast access, events archived for audit and replay.

Recoverability requires:

• The ability to replay a workflow instance from any historical point
• The ability to retry a failed task without rerunning successful tasks
• The ability to migrate a workflow instance from an old process version to a new one (the workflow version migration problem is one of the more difficult problems in BPM architecture)

Estates that take recoverability seriously avoid the situation where an incident requires manual reconstruction of workflow state from logs and side-effects. Estates that do not take it seriously eventually encounter that situation and remember it.

Task assignment and routing

Most BPM platforms support assigning tasks to specific users, groups, or roles. The architecture decision is which is the default.

User-direct assignment. Tasks go to a specific named user. Simple to model. Fragile when users go on leave, change roles, or leave the organisation.

Role-based assignment. Tasks go to whoever currently holds the role. Robust to personnel changes; requires a clear role model.

Skill-based assignment. Tasks go to whoever has the required skills, possibly weighted by current load. More sophisticated; requires a skills inventory the BPM platform can consume.

Queue-based assignment. Tasks go into a queue; users pull from the queue. Works well for high-volume operations centres; less suitable for low-volume strategic work.

The estates that work well usually layer these — most tasks are role-based with skill-based weighting, with the option for specific user assignment in escalation paths. The estates that drift are the ones where every task was assigned to a specific user during a hurry to ship, and the user model became the de facto reality.

The audit posture

We have covered audit-by-design as a workflow pattern in a separate piece. At the architecture level, the commitment requires:

• A canonical audit record schema. Every state transition emits the same shape — workflow instance ID, transition name, actor, timestamp, before-state, after-state, payload reference, rationale.
• An audit store with the right retention. Most regulated industries require seven years; the workflow platform's database is not the right retention tier for that.
• Audit availability that does not depend on the workflow platform. If the BPM platform is down, the audit history must still be queryable; otherwise the audit becomes hostage to the platform's availability.
• Auditor-friendly access. The audit must be queryable in a form an auditor can use, ideally without engineering intervention. Audit reports that require engineers to write queries each time produce friction at the worst possible moments.

These commitments are not free. They produce workflow estates that survive audits — including the unannounced ones — without late-night reconstruction sprints.

Integration with identity

Workflow tasks have actors. Actors come from an identity system. The integration between the BPM platform and the identity provider determines several operationally important behaviours:

• Single sign-on so users do not authenticate twice
• Group membership propagation so that role-based assignment reflects the current organisational reality, not a snapshot from when the workflow was designed
• Authentication audit so the actor recorded against a task is provably the actor who actually did the task
• Identity changes that flow through to the workflow platform — user leaves, user role changes, user is delegated

Most workflow estates we have rescued had degraded identity integration — group membership that was stale, audit gaps where the actor recorded was a service account rather than the human, propagation delays between identity changes and workflow effects. The remediation is mechanical but unglamorous.

What the platform decision falls out from

Once these architectural commitments are made — runtime placement, orchestration boundary, state persistence, task assignment, audit posture, identity integration — the choice of BPM platform is much smaller. Pega, IBM BAW, Camunda, Activiti, Bizagi, OutSystems Process Engine, ServiceNow Workflow — each can be made to support the commitments competently. The differentiation is in tooling depth, operational maturity, talent availability, and the commercial relationship.

The estates we have seen succeed are the ones where the architectural commitments came first and the platform choice fell out of them. The estates we have rescued are usually ones where the platform was chosen first and the commitments were retrofitted as a series of workarounds.

What to recommend

For a new workflow programme:

1. Decide the runtime placement explicitly. Document it.
2. Decide the orchestration boundary explicitly. Build the integration facade if BPM is the choice.
3. Specify the audit record schema as a first-class deliverable, not a side-effect.
4. Decide the task assignment model and the role model that underpins it.
5. Integrate with the identity system as a Day-1 commitment, not a Day-30 enhancement.

Only then choose the platform.

For an existing workflow estate that has drifted:

1. Audit the current architecture against the six dimensions above. Where are the gaps?
2. Pick the gap that produces the most operational pain. Close it.
3. Iterate.

Workflow architecture is rarely glamorous. The estates that hold up are the ones where the unglamorous structural decisions were made deliberately and held over years. The estates that drift are the ones where the structural decisions were made by accumulation rather than by design.