What does the Sales Order Agent read, and what does it skip?

It reads the email — subject, body and attachments — then searches your item catalogue across seven tables. What it skips is the more interesting half: a relevance model discards messages before processing, a second check discards non-sales attachments, and it refuses to identify a customer by name at all.

What does it actually read?

The email first, in three parts. Microsoft's description of the trigger:

"the agent analyzes the email—including subject line, body, and attachments (if configured)—to identify quote requests and extract relevant details. Attachments can be PDF or image files."

*Note "if configured".* Attachment reading is a setting, so an agent that appears to ignore a purchase-order PDF may simply not have been asked to open it.

Then your catalogue, in three passes. Microsoft calls it "a multi-layer strategy to find the best matching items":

And it reads across seven tables to do it — Items, Item Variant, Item Reference, Item Attributes, Item Category, Item Translation, Item Identifier — plus extended text lines.

Which makes item-data quality the lever, and Microsoft says so plainly: "the quality of product information in Business Central affects its effectiveness… You can improve the agent's ability to find products by enhancing descriptions, attributes, categories, and extended text." That is a data job, not an AI job, and it is the one thing on this page you can act on tomorrow.

What does it refuse to read?

Two filters, and both run before any processing happens.

"The agent validates incoming messages and attachments against a relevance model before it processes them. The relevance model filters out messages that are outside the agent's scope. For example, it filters out offers to sell, discount requests, or attempts to access internal data."

Read that third example again. Attempts to access internal data is not a relevance problem — it is a prompt-injection defence, sitting in a paragraph about scope.

The second filter is about attachments:

"A separate check runs on attachments to ensure non-sales-related documents don't trigger unnecessary processing. For example, if a customer attaches terms and conditions or a privacy policy alongside a purchase order, the agent processes only the purchase order and ignores the non-sales attachments."

And for anyone building on this: "The agent's prompt instructions, including the relevance and item-search rules, are included in the Sales Order Agent extension source code. Partners can inspect these prompts." That is unusually open — the filtering rules are readable rather than opaque.

How does it decide who the customer is?

By email address, and by nothing else — deliberately.

"For security, the agent identifies contacts exclusively by matching the sender's email address to the E-Mail field on contact cards. It doesn't search by contact name, company name, or other fields when establishing the security context. This restriction prevents unauthorized parties from impersonating a customer by using a similar name."

This is the sharpest design decision on the page. Name matching would be more forgiving and more useful — and it would let anyone who can spell a customer's name request that customer's pricing. Microsoft gave up the convenience.

The scope rule that follows from it: "The agent ensures that a request from one customer can't be about another customer's requests" — once identified, the agent filters to documents belonging to that customer alone.

The practical consequence is a support call waiting to happen, and Microsoft names it: "If you can see a contact in your contact list but the agent reports it as not found, check whether the contact's E-Mail field matches the address the customer sent from."

Does a person see the message before the customer does?

Yes. Every time — and this is stronger than it first appears.

The overview section describes human involvement softly: "Involvement might be needed in specific scenarios, for instance to review outgoing messages… based on configured preferences." Read alone, that sounds like a setting.

It is not. Further down the same page:

"The agent always involves designated Business Central users to review and approve all outgoing messages before it sends them to customers."

### The process flow settles it Microsoft's general flow alternates every single time: agent prepares → Reviewer reviews/confirms → agent sends. It happens for the quote email, for the order confirmation, and for the incoming request. There is no send step in that flow without a review step in front of it.

So the human checkpoint is on the outbound boundary, and it is not yours to remove. For the agent that writes to people outside your company, Microsoft hard-wired the gate rather than shipping it as a preference — which is the same internal-versus-external line that runs through where the built-in agents stop.

Why does it always create a quote first?

Because a quote is inert, and Microsoft explains the reasoning rather than just stating the rule:

"The agent always creates a sales quote as the first step, even when the customer asks for an order. Sales quotes have no impact on planning, reservations, availability calculations, or cash flow forecasts, which makes them a safe intermediate document for AI-assisted processing."

That is the most transferable idea on the page. The agent is not trusted with a document that moves supply; it is given one that moves none of those four things, and a person promotes it. If you build an agent against any ERP, look for your equivalent of the quote — the document that records intent without consuming anything.

Whether the customer ever sees it is the configurable part, and the setting names are published: "To configure the agent to go straight to orders, turn off Send quotes for confirmation and turn on Make orders from quotes in the agent setup."

What actually bites in practice?

Three things, all documented, none of them about extraction accuracy — unlike the Payables Agent, whose published limits are about the documents themselves.

Forwarding breaks identification. "When you forward an email to the agent's mailbox, the agent uses the forwarder's email address (not the original sender's) for contact lookup. If an internal team member forwards a customer's email, the agent doesn't automatically identify the customer." The fix is the Use another contact once option, which links a contact to that task only — "without modifying any master data". Use it, rather than creating a contact per forwarding address.

New item data is not instantly searchable. "It might take up to 15 minutes for newly entered data to become searchable as the system reindexes the tables in the background." An item created this morning and quoted this morning looks like a model failure and is a timing one.

And the agent resumes with a backlog. When it exhausts its Copilot Credits it "stops processing new emails but stays active and scheduled", and when credits return it "automatically resumes and processes all unprocessed emails that accumulated during the outage." That is a queue draining into a review inbox, and Microsoft's own advice is to "deactivate the agent when you don't need it running."

About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Agentic ERP. We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on Azure OpenAI, Microsoft Fabric and Copilot Studio. We build these on request, against your data and your environment.

More on the boundary between what Copilot does and what you build: Agentic ERP on Dynamics 365.

If an agent is going to read your customers' email, the filters and the identity rules matter more than the extraction. Bring one week of your own inbound requests to a 15-minute call.

Sources

• Sales Order Agent overview — Business Central · fetched and read in full 2026-09-15 · page states Last updated on 2026-07-23
• Payables Agent Overview — Business Central · ms.date 2026-05-03