Business Central Sales Order Agent: Test Before You Trust

A customer emails: "Same as last time, but send it to the other warehouse."

Your order desk knows why that sentence needs a follow-up. Which order? Which warehouse? The usual pack size, or individual units? Does the usual discount still apply?

That is the right starting point for evaluating Business Central Sales Order Agent. Choose a workflow, give it realistic requests, and check whether the resulting documents and customer replies are correct enough for your team to approve.

Use the checklist below to decide which requests to automate, which need review, and when to keep manual entry. The examples are illustrative; the pilot approach is Bitta Apps guidance.

Why Sales Order Agent deserves attention now

Microsoft's current setup documentation lists Sales Order Agent as generally available. Its documented workflow can turn customer email requests into quotes and orders, with people reviewing outgoing customer messages. This makes email order intake a concrete AI use case to evaluate. It does not tell you how well your own order mix will perform. Microsoft setup documentation; workflow overview.

The opportunity is easy to recognize if your team repeatedly moves customer requests from an inbox into Business Central. The useful pilot question is: can this workflow reduce handling effort while preserving the checks that make an order trustworthy?

What it does, and where the handoff remains

Sales Order Agent interprets emailed item requests, looks up Business Central data, and prepares sales documents. It starts with a quote internally. Configuration determines whether the customer sees that quote and whether it becomes an order. Every outgoing customer message requires user review and approval. Microsoft workflow overview.

Microsoft's FAQ says the agent does not post documents or modify existing sales orders. Pricing and default discounts come from Business Central business logic; requests to change them need a person. A useful pilot must therefore include the handoff to your order desk, not end when a document appears. Microsoft capability limitations.

A polished reply is not evidence that the right unit of measure made it onto the order.

Start with a deliberately narrow pilot

Choose a familiar customer group and a manageable product range. Use a representative sandbox, a controlled test mailbox, and designated reviewers. Confirm that test replies cannot reach real customers. Keep the manual order-entry path available.

For an initial quote-focused pilot, consider turning on quote review and turning off automatic order creation. Microsoft's setup offers separate controls for reviewing quotes, sending quotes for customer confirmation, and converting quotes into orders. Record the actual settings so everyone is evaluating the same process. Review and conversion settings.

Before testing, verify the supported language, localization, and data-movement configuration for your environment against the current Microsoft availability matrix. Recheck these details when approving production use.

The pilot checklist: test the requests your team has to think about

Customer identity and forwarded emails

Microsoft documents contact matching using the sender's email address. When someone forwards a request, the forwarder's address is used for lookup. Include both direct and forwarded messages in the test set. Customer identification rules.

Test: send the same illustrative request from a registered contact, an unfamiliar address, and an internal colleague. Have the reviewer verify the intended customer before accepting the document. Write down who resolves an unmatched sender and how the choice is checked.

Item identity, units, and delivery details

Test: use an exact item reference, a customer's nickname for that item, and a deliberately ambiguous description. Add a request for cases when your team also sells individual units. Then include a different delivery address and a requested date.

Pass evidence: the reviewer can trace the selected item, quantity, unit, destination, and date back to the request or an explicit clarification. An unresolved ambiguity should remain visible in your acceptance process. Do not count a plausible guess as a successful test.

Prices, discounts, and an unavailable item

Test: compare the draft against a manually prepared quote using the same customer, date, items, units, quantities, and location. Include a customer asking for a special discount and an item that is unavailable for the requested shipment.

Pass evidence: the reviewer understands any price difference and the response makes only a delivery commitment the business has verified. Keep a named person responsible for exceptions and commercial decisions.

Custom AL fields and extension permissions

Microsoft explains that the agent works through page metadata and actions. Its ability to encounter custom fields does not establish that your extension workflow is compatible. The FAQ explicitly calls for thorough testing of custom elements. How the agent interacts with Business Central; Customization limitations.

Test: include a required customer reference, a delivery instruction, and any extension-controlled pricing rule your chosen workflow uses. Run the test with the agent's assigned permissions, and check the resulting document as the downstream warehouse or finance user would.

Pass evidence: required information survives the handoff, validation errors have a clear resolution, and the extension owner can explain the result. Use the AL test automation guide to protect deterministic extension behavior alongside these end-to-end trials.

Exceptions and reviewer availability

Test: include a changed request after order creation, a duplicate-looking message, missing details, and a reviewer who is unavailable. These are acceptance scenarios to investigate, not claims that the agent automatically resolves them.

Pass evidence: someone owns each unresolved request, knows whether a customer reply or document already exists, and can continue manually without creating another order. Give the backup reviewer enough context to take over.

Measure the whole request, including the corrections

Sales Order Agent uses Copilot Credits. Consumption depends on the interactions performed, so a completed order is not a universal fixed-price unit. Use the current Microsoft consumption-billing documentation when preparing your estimate.

Keep a simple pilot log for each request: request type, manual handling effort, agent-assisted review effort, corrections, unresolved exceptions, elapsed time, and observed consumption. Separate active work from waiting for a customer or reviewer.

Compare like with like. A clean repeat order and a request with uncertain items and a discount discussion belong in different groups. Look for a workflow where the business gains useful capacity after supervision and correction effort are included. Set your own acceptance criteria before looking at the results.

Decide whether to expand, adjust, or pause

• Expand when the selected request type produces acceptable documents and replies, reviewers have capacity, and the measured economics make sense.
• Adjust when a specific data problem, configuration choice, or extension behavior explains the failures. Fix that boundary and repeat the affected scenarios.
• Pause when ownership is unclear, important errors escape review, or corrections erase the benefit.

Return to the opening email. Your pilot is useful when it shows how the workflow resolves "same as last time" and "the other warehouse," who checks the answer, and what happens when the answer is still missing.

Bitta Apps helps teams examine the AL extensions and business rules behind these handoffs. If your pilot exposes a customization question, bring the example request, expected document, and observed result to a conversation: discuss your Business Central workflow.

Product documentation checked September 10, 2026. Recheck behavior, availability, and billing before rollout. This checklist is a starting point for your own acceptance testing.