Most agent pilots get scoped by whoever is paying for them. Accounts payable funds an invoice-matching agent. Procurement funds a purchase-order agent. Each one gets built to fit inside the department that wrote the check.
That works fine for the first few weeks. Then a real transaction crosses into a neighboring team’s territory, and the agent stops. It was never given permission, context, or a reason to follow the work past the department boundary it was built inside.
Microsoft’s own guidance for Dynamics 365 organizes the whole ERP story around a different unit altogether: end-to-end processes, not modules or departments. That framing is Microsoft’s. What we build on top of it in this piece — that agents should be scoped the same way — is our own conclusion, and we say so plainly further down.
What the Business Process Catalog Actually Says
Microsoft publishes a reference called the Dynamics 365 Business Process Catalog. It names fifteen end-to-end business scenarios: acquire to dispose, case to resolution, concept to market, design to retire, forecast to plan, hire to retire, inventory to deliver, order to cash, plan to produce, source to pay, project to profit, prospect to quote, record to report, service to deliver, and administer to operate.
Each one describes a flow of work, not a department. Source-to-pay runs from identifying a need to paying the vendor. Record-to-report runs from a transaction hitting the books to a finished financial statement. Neither of those is something one team owns start to finish.
Record-to-report is the clearest example. Microsoft’s own guidance describes it spanning general ledger, accounts payable, accounts receivable, fixed assets, budgeting, and consolidation. In most companies, each of those sits with a different team, sometimes a different system. The process is one thing. Department lines split it into six.
That split is exactly where department-scoped agent pilots run into trouble. The Catalog does not say this outright. But it does something almost as useful: it hands you a vocabulary for describing work the way it actually flows, instead of the way headcount happens to be arranged.
Why Pilots Stall at the Boundary
A department-scoped pilot is easy to fund and easy to explain. Someone in accounts payable wants fewer manual invoice matches. A vendor of theirs makes a compatible product. The pilot gets approved because it solves a problem one person can see.
It also gets built to only see what that person can see. The agent gets access to accounts payable data, accounts payable approval rules, and an accounts payable owner to answer questions. Procurement never enters the scoping conversation, because procurement did not fund the pilot and had no reason to be in the room.
The first exception exposes the gap. A vendor invoice does not match the purchase order on file, because the PO itself was amended in procurement’s system after issue — a routine change, invisible to an agent that only sees the AP side. A human in accounts payable would pick up the phone and ask procurement what happened. The agent has no equivalent move. It was never given a reason to know procurement exists.
The agent’s underlying model and platform have nothing to do with this. The gap traces back to a scoping decision made before the agent was built: whose department got to define what this agent is allowed to know about.
Here is an illustrative version of how that plays out, not a documented case, to make the shape of the problem concrete.
A manufacturing company builds an invoice-matching agent for its accounts payable team. The pilot goes well for two months. Every invoice the agent sees matches cleanly against a purchase order already in the system.
Then a supplier raises its price mid-contract, and procurement approves a revised PO to reflect it. Procurement’s system logs the change. Accounts payable never hears about it directly — under the old manual process, the paper trail caught up eventually, usually when someone in AP picked up the phone to ask. The agent has no equivalent instinct to ask. It sees an invoice that no longer matches the PO it was scoped to check against, flags it as an exception, and stops. A person now has to intervene on every price revision, which was supposed to be exactly the category of routine work the agent was built to remove.
A smarter matching algorithm will not fix this. What fixes it is giving the agent visibility into the procurement side of the same transaction, and that means procurement has to be part of the agent’s design from the start — added at the design table, not called in once the exception rate has already made the pilot look broken.
Finding the Process Behind an Existing Pilot
Most Dynamics 365 teams do not start from a blank page. They already have a department-scoped pilot running, or one nearly ready to launch, and the question is not whether to rebuild it but whether it is missing a boundary it will eventually hit.
The Business Process Catalog is a useful diagnostic for exactly this. Take whatever the pilot currently does and ask which of the fifteen named processes it actually sits inside — source-to-pay, record-to-report, hire-to-retire, whichever applies. That single question usually surfaces the neighboring department that was left out of the original scoping conversation.
It also surfaces something less obvious: some pilots turn out to sit inside more than one process at once. An invoice-matching agent touches source-to-pay directly, but a persistent mismatch between the PO and the invoice eventually becomes a record-to-report problem too, once it affects what shows up in the ledger. A pilot scoped only to the first process will keep missing that second one.
A Real Example of Scoping by Process Instead
Microsoft published a concrete example of the alternative in June 2026, describing how Sonata Software approached agentic ERP within its own Dynamics 365 environment. Sonata built a Vendor Onboarding Agent that Microsoft describes as working across procurement and accounts payable — one agent, spanning both sides of a process that a department-scoped design would have split in two.
That detail matters more than it looks. Vendor onboarding runs as one continuous flow: identify the vendor, verify it, set up payment terms, and get it ready to be paid correctly the first time an invoice arrives. Splitting that flow into two agents, one per department, recreates the exact handoff gap a single, process-scoped agent is built to close.
Sonata’s design gave the source-to-pay process one agent that follows the vendor across both halves of the work, rather than handing procurement and accounts payable separate agents that each see half the picture. That is process scoping, demonstrated in production rather than theorized.
This Is Our Own Reading, Not a Microsoft Prescription
Here is where we want to be plain about what is documented and what is our own conclusion. Microsoft has published the Business Process Catalog and its fifteen named processes. Microsoft has published the Sonata example as a real deployment. Microsoft has not published a statement saying “scope your agents by process, not by department, because department-scoped pilots stall at the first cross-team exception.”
That connective argument is ours. We think it follows directly from the two facts above, and we think it explains a pattern many Dynamics 365 teams will recognize from their own pilots. But it is DAX’s synthesis of Microsoft’s material, not a claim Microsoft itself has made, and we want that distinction on the record before you act on it.
What Process Scoping Actually Changes
Scoping an agent to a process instead of a department changes three practical things before the agent is ever built.
It changes who signs off. A process-scoped agent for source-to-pay needs procurement and accounts payable to agree on what it can do, not just the department that happened to propose it first. That conversation is slower to start. It is also the conversation that prevents the boundary problem later.
It changes what data the agent needs on day one. An agent built for record-to-report needs visibility into general ledger, fixed assets, and consolidation from the outset, even if the first use case only touches one of them. Building it narrow and expanding later usually means rebuilding its access model from scratch once the first exception shows up.
It changes how success gets measured. A department-scoped pilot gets judged on whether it helped that department. A process-scoped agent gets judged on whether the whole flow — vendor to payment, transaction to statement — got faster or more accurate end to end. That number takes longer to produce, but it describes what the business actually experiences.
Where Department Scoping Still Makes Sense
This does not mean every agent needs to span an entire process from day one. A narrow, single-department pilot can be the right way to prove an idea works before anyone commits to the harder cross-team conversation.
The distinction that matters is whether the narrow pilot is a deliberate first step toward a process-scoped design, or whether it is the entire plan. A team that says “we’re starting with accounts payable and we already know procurement needs to join before this goes live” is scoping by process, with a staged rollout. A team that never has that conversation is scoping by department, permanently, and will meet the same boundary the first time a real transaction requires it.
The Business Process Catalog is useful here even for a narrow pilot. It tells you, in advance, which of the fifteen processes your department-sized pilot actually sits inside — and which neighboring teams sit inside the same process, whether or not they are in the room yet.
The Piece That Connects the Other Four
We have written about scoping agent chains, action-level permissions, security roles, administrative responsibility, and tenant sprawl. Each of those pieces assumes an agent’s boundary has already been drawn somewhere, and asks whether the governance around it is sound.
This piece is about where that boundary gets drawn in the first place. Get the process boundary wrong, and every governance layer built on top of it — the roles, the permissions, the administrative ownership — is scoped to the wrong shape of work from the start.
If your organization is scoping its next agent pilot around a department because that is where the budget sits, DAX Software Solutions can help you map it against the actual end-to-end process first. Get in touch while the pilot is still on paper — that is the point in the project where adding a neighboring department to the design is easy, and the only point where it stays that way.