A purchase order at a Tier 1 automotive supplier sat flagged in Business Central for six hours last quarter. The exception was real. A freight delay had pushed the delivery window past the customer's cutoff. BC recorded the flag the moment the delay posted to the order. Nobody routed it to a person who could act on it until a plant manager stumbled on it during a Friday afternoon review. The ERP had done its job. Nothing downstream of that job existed.
Tom Luttrell, CIO of automotive supplier CSP, named this exact gap on the Auto Supply Chain Champions podcast in June 2026. Talking with hosts Jan Griffiths and Tom Roberts, Luttrell described moving manufacturers off systems built to log a transaction and toward systems built to sense a problem and put it in front of the person who owns it. The episode's own framing was direct: "Traditional ERP systems capture transactions. Modern systems sense issues, trigger action, and help teams respond in real time before problems escalate." Luttrell pointed to disconnected infrastructure, fragmented workflows, and information silos as what actually slows execution on the shop floor. Data isn't the constraint.
A system of record captures and stores what happened: a confirmed order, a posted receipt, a closed work order, with enough integrity to audit later. A system of action takes that same signal and moves it. It identifies who owns the next step, gets them the context, and tracks whether they acted inside a defined window. Business Central is an excellent system of record. It was never architected to be the second thing.
The instinct when a decision stalls is to blame the ERP: bad configuration, missing module, needs an upgrade. That instinct is usually wrong. A perfectly configured, fully populated Business Central instance still won't get a flagged exception to a named owner inside an hour, because recording a transaction and executing a decision are two different jobs, built on two different assumptions about who's watching.
What a system of record does, and where it stops
Business Central's job is to be right. Every posted transaction, every inventory movement, every purchase order revision lands in a schema built for audit-grade accuracy. That is genuinely hard to get right at scale, and BC does it well. Ask any CIO who has migrated off a legacy ERP how much of the project went into getting the data model trustworthy again.
But a system of record is passive by design. It waits. A flagged exception sits in an aging report, a filtered list, a dashboard tile, until a human opens that specific view and notices it. Nothing in BC's architecture pushes the exception to a person, assigns a deadline, or escalates when the deadline passes. The record is accurate. It is also, on its own, inert.
Written from 5+ manufacturing and distribution engagements, 2022–2026, where a healthy, well-configured Business Central instance still left exceptions sitting unrouted for hours or days at a time.
System of record vs. system of action: the five questions that separate them
The distinction isn't abstract. It shows up as five concrete differences in how a decision moves once BC has flagged it.
| Question | System of record (BC alone) | System of action (decision infrastructure layer) |
|---|---|---|
| Primary job | Log the transaction accurately after it's confirmed | Route the exception to a named owner before it compounds |
| What triggers movement | A person opens the record and looks | A signal crosses a threshold and pushes to the owner |
| Where the exception lives | An aging list, a filtered report, a dashboard tile | An approval card in Teams, with full context attached |
| Systems it can reach | Whatever sits inside the ERP's own schema | BC plus freight portals, WMS, supplier systems, Teams |
| If nobody looks | Nothing happens: the record stays accurate and idle | An SLA clock runs and an escalation path fires |
The system-of-record column optimizes for what's true after the fact. The system-of-action column optimizes for what happens next. Both matter. Most manufacturing operations only have the first one built.
Why disconnected systems turn a healthy Business Central instance into a slow decision
A single BC exception rarely resolves inside BC alone. A late-shipment flag has to cross a freight visibility platform like project44 or FourKites to confirm the new ETA, a warehouse management system like Manhattan Associates or Blue Yonder to check downstream slotting, and a Microsoft Teams thread where the actual approve/deny conversation happens, before anything gets written back to BC as a resolved decision. That is what makes this harder than adding a notification.
Every one of those handoffs is a place a decision can stall with no owner. BC has no reach into any of them. It can flag that a PO is late. It cannot see that the freight portal already confirmed a two-day slip, that the WMS has a slotting conflict on the replacement shipment, or that the Teams message asking for a sign-off has sat unread since Tuesday. Luttrell's point about disconnected infrastructure and information silos is exactly this: the systems aren't broken individually. They just don't talk, and nothing owns the conversation between them.
Most operations teams have never scored where their own BC exceptions stall between those handoffs. The answer isn't hard to find. Nobody has measured it.
Take the Decision Latency Diagnostic →
The decision infrastructure layer between record and action
This is the same distinction we argue under the name decision infrastructure. A decision intelligence tool, a dashboard, a forecasting model, an alerting layer, makes the signal better. It still leaves the question of who acts, how fast, and whether the action is provable later, unanswered. Decision infrastructure is the layer that answers it: a named owner, a response window, and an audit trail connecting the original signal to the ERP write that closed it. We've written the full architecture behind that distinction here. The short version: a system of action and decision infrastructure are the same idea described from two different starting points, one from the ERP side, one from the governance side.
OpsGrid, IntelliConnectQ's decision infrastructure layer for Dynamics 365 Business Central, is built as the system-of-action counterpart to BC's system of record: a Signal → Route → Approve → Execute → Audit architecture that surfaces the exception inside Teams, holds a named owner to a response window, and requires human sign-off before anything writes back to BC. BC stays the record. OpsGrid becomes the action.
Frequently asked questions
What's the difference between a system of record and a system of action?
A system of record stores what already happened with enough integrity to audit later: a confirmed order, a posted receipt, a closed work order. A system of action takes that same signal, identifies who owns the next step, delivers the context they need, and tracks whether they acted inside a defined window. Business Central does the first job well. Closing the second requires a layer built specifically for routing, approval, and audit, not a bigger ERP module.
Does Business Central need to be replaced to become a system of action?
No. The fix sits on top of Business Central, not inside it. A decision infrastructure layer reads BC through its API, routes the exception to a named owner in a channel they already use, most often Microsoft Teams, and writes the outcome back only after a human approves it. BC's data model and configuration stay untouched. What changes is what happens between the signal and the person who has to act on it.
What is decision latency in a Business Central environment?
Decision latency is the time between a signal landing inside BC (a flagged purchase order, a stockout risk, an aging exception) and a qualified person committing to and recording a response. Most mid-market manufacturers have never measured it directly, because the gap spans systems and functions with no single owner, and a healthy ERP gives no visible sign that a decision is stalled behind it.
Which systems typically sit outside Business Central's reach in manufacturing operations?
Freight visibility platforms like project44 and FourKites, warehouse management systems like Manhattan Associates and Blue Yonder, supplier portals, and the Microsoft Teams threads where approvals actually happen. A decision that starts as a BC exception routinely has to cross three or four of these before it's resolved, and BC alone has no reach into any of them.