Business Central just became agentic, and it happened faster for small and mid-sized businesses than almost anyone expected. In the 2026 release wave, Microsoft shipped the Sales Order Agent, which reads customer emails and drafts sales orders on its own, alongside broader automation of sales and purchase order scenarios. Then it went further: with Agent Designer and Copilot Studio now generally available, any BC team can build its own custom agents by describing what they want in plain language, no AL developer required.
For the lean finance and operations teams that run most Business Central shops, this is genuinely transformative. It is also a quiet governance problem. These agents don’t just draft, they create and modify records, check availability, and turn quotes into orders. And the same low-code simplicity that lets a non-developer build an agent in an afternoon also means agents can now be created by people who have never written a test in their life. This article is about closing that gap: how a small Business central team validates what its sales and purchase order agents, built-in and custom, actually decide, without needing a QA department it doesn’t have.
What the Business Central sales & purchase order agents automate
Start with what the agents actually do, because that defines what has to be tested. Business Central’s order automation comes in two forms, and both matter for a testing plan.
The built-in Sales Order Agent
The Sales Order Agent is Microsoft’s out-of-the-box agent for order-taking, and it does a lot on its own. It monitors a designated mailbox, reads incoming customer emails including PDF attachments, identifies the customer, maps requested line items to your product catalog, checks item availability, generates a quote and formats it as a PDF, manages the follow-up email exchange, and, after user confirmation, converts the quote into a sales order. Every action it takes is logged under the agent’s own user ID and appears in list views, history, and posted documents exactly like a human user’s actions would.
Sales and purchase order automation, and custom order agents
Beyond the built-in agent, the 2026 wave expands agentic automation across both sales and purchase order scenarios, and Copilot can map incoming e-documents to purchase order lines. Just as importantly, Agent Designer and Copilot Studio let teams build their own order agents, including purchasing and procurement agents, tailored to their process. A custom agent built this way can perform create, read, update, and delete operations on BC records such as customers, vendors, items, and orders, acting as the user and respecting that user’s permissions.
The line that matters for testing These agents don’t only suggest, they act. The Sales Order Agent creates and modifies records and converts quotes to orders; a custom agent can create, update, and delete BC data directly. The moment an agent can write to your order and master data, the question stops being “is it helpful?” and becomes “is it correct?”, and that is a testing question.
Low-code agents raise the testing stakes for lean teams
There is a comforting assumption worth dismantling right away: that because these agents are easy to build and a human stays in the loop, they don’t need much testing. For a small BC team, the opposite is true, low-code agent creation raises the testing stakes, for three reasons.
- The people building agents aren’t the people who write tests. Agent Designer is built so a functional user can create an agent in natural language. That is the point, but it also means agents are now authored by people who have never had to think about test coverage. The skill needed to build has dropped; the skill needed to validate has not.
- Lean teams have the least slack to catch errors manually. A large enterprise has a QA function and layers of review. A ten-person BC shop has a controller and an ops lead who are already stretched. When an agent drafts a wrong order, there is often no second set of eyes, the agent’s output goes almost straight through.
- The agents make systematic errors, not random ones. If an agent misreads a particular customer’s email format or consistently maps a product to the wrong catalog item, it does so every time, across every order of that type. That is exactly the error a busy human approver skims past, and exactly what testing is built to catch.
Put together, these mean the easier it becomes to create agents, the more important it becomes to validate them, precisely because the teams creating them are the least equipped to notice when one quietly goes wrong. The same risk applies on the accounts-payable side: Business Central’s Payables Agent drafts vendor invoices for approval and can mis-read or mis-code them in exactly the same systematic way, which is why we cover it separately in Testing the Business Central Payables Agent.
Validating BC agent decisions without a big QA team
The good news is that testing an order agent does not require an enterprise QA department. It requires validating the right things, the decisions the agent makes, against a known-correct answer. For a sales or purchase order agent, that comes down to four checks.
- Right customer or vendor. Confirm the agent identifies the correct party, including the confusable cases: similar names, a new customer that shouldn’t match an existing record, or an email from a known contact at a different company.
- Right items and quantities. Validate that requested line items map to the correct catalog products at the correct quantities, the most common systematic error, since a mis-mapped item repeats across every similar order.
- Right pricing and availability. Confirm the quote reflects correct pricing, discounts, and the real availability check, an order promised on stock that isn’t there is a customer problem, not just a data one.
- The confirmation gate holds. The Sales Order Agent converts a quote to an order only after user confirmation. Confirm that gate can’t be bypassed, that no path lets the agent post an order without the human step it’s designed to require.
| What to validate | What “correct” means | A realistic failure to test for |
| Customer / vendor match | Resolves to the right party record | A new customer force-matched to an existing one |
| Item mapping | Line items map to the right catalog products | One product consistently mapped to the wrong item |
| Pricing & availability | Correct price, discount, and real stock check | A quote promised on unavailable inventory |
| Confirmation gate | Agent posts only after human confirmation | A path that converts a quote without sign-off |
None of these require a QA specialist to define. They require someone who knows what a correct order looks like, which every BC team already has, and a way to check the agent’s output against that expectation automatically, at the data layer, rather than by eye.
This four-part discipline isn’t unique to order agents. It’s the same approach you’d use to validate any autonomous finance agent, the D365 Account Reconciliation Agent, for example, has to be checked the same way: its matches and exceptions validated against a known-correct outcome, in the data, not on the screen. Once your team internalizes the pattern on one agent, it transfers to the next.
Testing custom agents built in Copilot Studio
Built-in agents are validated against known behavior. Custom agents, the ones your team builds in Agent Designer or Copilot Studio, need more testing, not less, because you designed the logic and no one at Microsoft validated it for your process. Two things specific to custom agents deserve direct testing.
Permissions and scope, what can this agent actually touch?
A Copilot Studio agent connected through the Business Central connector acts as the user and respects that user’s BC permissions, and the BC MCP server is read-only by default until it is explicitly configured to allow create, update, or delete operations. That configuration is exactly where a lean team can make a costly mistake, granting an agent broader write access than it needs. Test the scope directly: confirm the agent can do what it should and, just as importantly, cannot write to data it was never meant to touch.
The logic you wrote, does it do what you meant?
When you describe an agent in natural language, the system generates the logic, and natural language is ambiguous. The agent you got may not be the agent you meant. Validate custom agents against concrete scenarios with known-correct outcomes: feed them the real situations they’ll face, including the edge cases, and confirm the decisions match what you intended. This is the step most low-code builders skip, because building felt so easy that testing feels unnecessary, which is precisely the trap.
The silent-failure risk for custom agents A custom agent with slightly-too-broad write permissions and a subtly-wrong piece of generated logic won’t throw an error. It will confidently create or modify BC records the way it was (mis)built to, quietly, at scale, until someone notices the data is wrong. On a lean team with no QA net, “until someone notices” can be a long time. Testing the agent before it runs on real data is the only reliable way to catch this.
How Sofy makes safe agent adoption realistic for BC
The reason agent testing feels out of reach for a small BC team is that traditional test automation was built for developers and enterprises, exactly what these teams don’t have. Sofy is built the other way around: no-code testing that a functional BC user can run, designed for validating agent decisions rather than replaying developer scripts. That combination is what makes safe agent adoption realistic for a lean team.
No-code testing for teams without QA specialists
Business Central ships only the AL Test Framework for unit-testing code, a developer tool, and there’s no RSAT-style option for business-process testing on the BC side. Sofy fills that gap with no-code, process-level validation: the same controller or ops lead who knows what a correct order looks like can define that expectation and validate the agent against it, without writing AL or standing up a test framework. The skill you need to test with Sofy is the skill your team already has, knowing your own business.
Validate the decision, at the data layer
Sofy checks what the agent actually produced, the customer, items, quantities, pricing, and the resulting order, against a known-correct expectation in the data, not the tidy summary on screen. A draft order that looks fine but mapped the wrong item still fails the test. For custom agents, that same outcome-based check confirms the logic you described does what you meant and the agent stays within its permitted scope.
It keeps working as your agents and Business Central evolve
Business Central updates monthly and its agents are expanding fast. Sofy’s tests self-heal through those updates, so validation keeps pace instead of breaking every release, which matters most for a small team that can’t afford to rebuild tests every month. You add an agent, prove it’s right, and the proof keeps holding as the platform moves.
Getting started: validate one agent, one workflow
You don’t need a testing program to start safely, you need to prove one agent on one workflow, then build from there.
- Start with the Sales Order Agent. It’s the most active and the highest-volume, so a systematic error there compounds fastest. Validate it first.
- Build a known-answer test set from real orders. In a sandbox, use real customer emails and orders where you already know the correct outcome, including your trickiest customers and item mappings.
- Validate the four decisions and the gate. Confirm customer, items, pricing/availability, and that the confirmation gate holds, at the data layer, not by eye.
- Then test every custom agent before it touches production. For each agent your team builds in Copilot Studio, check its scope and its logic against known scenarios before you let it run on real data.
Done this way, a lean BC team gets the full upside of agentic automation, fewer manual orders, faster order-to-cash, without betting the accuracy of its order book on an agent nobody validated.
Frequently asked questions
What is the Business Central Sales Order Agent?
It is Microsoft’s built-in AI agent for Business Central that automates sales order-taking. It monitors a mailbox, reads incoming customer emails (including PDFs), identifies the customer, maps line items to your catalog, checks availability, generates a quote, manages follow-up email, and converts the quote into a sales order after user confirmation. Every action is logged under the agent’s own user ID, and the agent brings a person in for review and approval.
Do Business Central AI agents need testing if a human approves the orders?
Yes, arguably more than enterprise agents do. The human-in-the-loop only protects you if the reviewer scrutinizes each draft, and the agent’s purpose is to reduce that manual review. Lean BC teams have little slack to catch errors by eye, and AI agents make systematic errors (misreading a customer’s format or mis-mapping an item the same way every time) that manual review is especially poor at catching. Testing validates the agent’s decisions before they reach a reviewer.
How do you test a custom agent built in Copilot Studio for Business Central?
Two things need direct testing. First, permissions and scope: a Copilot Studio agent acts as the user and respects BC permissions, and the BC MCP server is read-only until configured otherwise, so confirm the agent can only write to the data it should. Second, the generated logic: because you describe custom agents in natural language, validate them against concrete scenarios with known-correct outcomes to confirm the agent does what you actually meant, including edge cases.
Can a small Business Central team test AI agents without developers?
Yes. Business Central’s native AL Test Framework is a developer tool for unit-testing code, but no-code testing platforms let a functional user validate agent decisions at the process level. The skill required is knowing what a correct order looks like, which every BC team already has, rather than writing test code. That makes agent validation realistic for lean teams without a dedicated QA function.
How does Sofy help Business Central teams test their agents?
Sofy provides no-code, process-level testing that a functional BC user can run, purpose-built to validate agent decisions rather than replay scripts. It checks what an agent actually produced, customer, items, quantities, pricing, and the resulting order, against a known-correct expectation at the data layer, confirms custom agents stay within their permitted scope, and self-heals through Business Central’s monthly updates so tests keep working as agents evolve..
Adopt BC Agents Without Adding a QA Team
Sofy’s no-code testing lets lean Business Central teams validate what their Sales Order and custom agents actually decide, at the data layer, with a record for every order. Safe agent adoption, no developer required.
