Learn
System of Action vs System of Record vs System of Engagement
Three layers, three different jobs. What each one owns, where each one stops, and why the layer that finishes work has to sit above the others.
The short answer
A System of Record owns authoritative data for one domain. A System of Engagement owns the conversation where a request starts. A System of Action owns the process that crosses both: it applies policy that spans systems, stops for human approval where the policy says it must, writes back into the systems of record, and leaves behind a record of what happened.
The three layers
| Layer | What it owns | Typical examples | Where it stops |
|---|---|---|---|
| System of Record | Authoritative data for one domain | ERP, CRM, HRIS, contract repository | The record is updated |
| System of Engagement | The conversation and the request | Chat assistants, search front ends, collaboration tools | An answer or a draft is returned |
| System of Action | The process that crosses the others | Cross-system WorkStreams with policy and approvals | The outcome is completed and recorded |
The layers are complements, not replacements. Records stay authoritative, interfaces stay where people ask, and the process layer coordinates between them.
Why a System of Record cannot run the process
Each system of record is excellent inside its own boundary and was built to be authoritative there. A purchase that starts as a request in a chat thread, passes a budget check in the ERP, needs a supplier verified against an external registry, a contract negotiated in a contract repository and an approval from a cost-center owner is not one system's work. It touches four.
Three limits follow. Policy that spans systems cannot be enforced by a system that only sees its own data. Exceptions that arise between systems have no owner inside either one. And the evidence of what happened ends up scattered across four audit logs that were never designed to reconcile with each other.
There is also a commercial limit. No enterprise will let one record vendor govern processes that run through its competitors' systems, so the process layer has to sit independently above the stack rather than inside any one of them.
Why a System of Engagement cannot run it either
Retrieval and chat tools read across the enterprise and answer questions about what exists. That is genuinely useful, and it is a different job. Their unit of work is a response. When the answer is delivered, the session ends.
A business process does not end there. It waits three days for a supplier, gets escalated when the budget owner is on leave, resumes under the rules it started under and produces artifacts that an auditor will ask about a year later. That requires durable state, not a conversation history.
Governance is the second difference. If the rules live in the interface, they apply only to requests that arrive through that interface. Rules enforced in the engine that runs the work apply to every path into it.
What a System of Action needs
Coordination alone is not enough. Four properties separate a governed System of Action from a set of connected automations:
- Policy that spans systems, so the same rules apply no matter which application a step touches.
- Stages with tollgates, so work pauses for a named human approver where the policy requires it.
- Runs bound to a Playbook version, so a change made mid-flight does not rewrite the rules an in-progress run is executing under.
- An Execution Ledger written by the runtime, so the record of every step, decision and approval is a byproduct of running the work rather than something assembled afterwards.
VeroTX is a System of Action for enterprise work built on those four properties. It reads from and writes to your existing systems of record through connectors and leaves them authoritative.
Where to next
Read deeper
Product and platform pages on the same topic, drawn from the VeroTX knowledge base.
Search everything in one place in the Research Center, or ask Veroli, which answers from the same knowledge base.