Sales Order Agent or a companion quoting workspace

Sales Order Agent or a companion quoting workspace — which request goes where?

The wrong question is which one is better. They are not aimed at the same request.

Business Central's Sales Order Agent [GA] is built for a specific, common and entirely legitimate shape: an email from someone you already have on file, arriving in a shared Exchange inbox, asking for a manageable number of catalogue items. For that request it is very good, it is already in the product, and anything built alongside it should stay out of the way.

The useful question is what proportion of your inbound looks like that, and what the rest needs.

For the partner or owner deciding what to switch on and what to build. 8 minute read.

Not a contest, and this matters commercially

A comparison written as a contest produces a recommendation. A comparison written as a sorting exercise produces a plan, and a plan is what a distributor can act on next week.

There is also a practical reason not to frame it as competition: the agent costs nothing to try. It is in the product, activation is pointing it at a mailbox, and billing is per interaction through Copilot Credits. Anyone advising against switching it on before knowing what it handles is advising against the cheapest possible experiment.

What the agent does better, said plainly

Four things, and each is a real advantage rather than a courtesy.

Nothing to integrate. "The agent is readily available in the product." No connection, no credentials, no permissions conversation with a partner, no data leaving anything.

It is a first-class ERP citizen. "The agent runs as its own user in Business Central and is granted access only to the necessary parts of the product. It comes with a predefined permission set and UI role (profile)." Every action carries its user ID, and approval workflows apply to it exactly as they do to a person. Nothing built outside the ERP gets that for free.

Delivery dates from the planning engine. Capable-to-promise "evaluates production capacity, procurement timelines, and supply chain constraints to determine when an item can realistically be delivered" — using data an outside system would have to ask for.

Prices from the real pricing engine. It builds a temporary sales document and applies "customer price groups, customer discount groups, and line discount rules", so the number is "the actual price the customer would see on a quote, not the list price from the item card."

That last one is worth pausing on. A companion system has to reach the same pricing logic through an interface. The agent is standing inside it.

The sorting test: six questions about a real request

Run these against a week of your actual inbound. Each is answerable from Microsoft's published boundary, so nothing here is a judgement call.

How did it arrive? — Inside the agent's scope: A shared Exchange inbox · Outside it: Gmail, a portal, a web form, a file drop, a messaging app, EDI
How many lines? — Inside the agent's scope: Up to fifteen · Outside it: More — Microsoft states quality drops beyond that
Does the item have a variant? — Inside the agent's scope: No variant needed · Outside it: Size, colour, finish or bore — the Variant Code field is left empty
Is the sender on a contact card, with that email address? — Inside the agent's scope: Yes · Outside it: An unrecorded address, a forwarded message, a phone number
Does the request involve a price negotiation? — Inside the agent's scope: No · Outside it: "Requests for changing discounts and pricing aren't accepted by the agent"
Does the line need a supply decision? — Inside the agent's scope: No — stock answers it · Outside it: Several suppliers, different costs, a margin choice

Every "outside" answer is Microsoft's own documented boundary, not our characterisation. Chapter 11 carries all of them in full, quoted.

What sits outside, and what it actually needs

Sorting is only useful if the other pile has an answer. It does, and the answers are the rest of this cluster.

A request arriving anywhere else needs one queue that all channels feed, with the clock visible on every row — chapter 1.

A long or messy request needs per-line uncertainty, because forty lines cannot be reviewed the way fifteen can. Something has to say which three to check — chapter 8.

A variant-bearing catalogue needs the attribute that resolved the match to travel with the match, and to appear on the quote — chapter 6.

An unidentified sender needs to be shown as unidentified rather than guessed at, and needs a route to becoming a customer — chapter 2.

A supply decision needs the alternatives, their lead times, and the margin at your quoted price, on the line — chapter 9.

None of those is a criticism of the agent. They are the shape of what is left over, and the size of that pile is a fact about your inbound rather than about either system.

They are not alternatives, and the sequence matters

The honest recommendation for most Business Central distributors is both, in order.

Switch the agent on. It is in the product, it costs an activation, and after a fortnight you will know — from real traffic rather than from a table like the one above — what share of your requests it closes and what share it hands back.

That measurement is the actual deliverable. It converts an architecture argument into a number somebody can act on, and it is a number no vendor can supply for you, because it depends entirely on how your customers happen to write.

Then look at the pile it hands back. If it is small, you have a good outcome and a cheap one. If it is large, you now know exactly what shape it has, and the rest of this cluster is about building for that shape.

If you run both, mind the mailbox

One practical point that only appears once both are live, and it is worth knowing before rather than after.

Two systems reading the same inbox need a way not to answer the same message twice. Microsoft's agent handles its own side of this with a marker:

"The agent processes all emails in the configured folder starting from the activation date, regardless of read status. To avoid reprocessing, it applies a Processed by Sales Order Agent category to each email after importing it. The agent skips emails that already have this category."

There is also an optional Mark email as read setting, which Microsoft describes as "making it easy for team members to identify processed messages."

So the coordination primitive already exists, and anything else reading that mailbox should respect it rather than invent a second one. The failure mode if nobody does is not subtle — a customer receives two quotes for one request, from the same distributor, and they will not agree.

The cleaner arrangement is usually a routing decision made before either system sees the message: separate folders, or separate addresses, with the sorting rules from the section above deciding which gets what.

How to run this on your own week

Take five working days of inbound and sort every request with the six questions above. Count the two piles.

Two things usually surprise people. The proportion arriving outside Exchange is higher than anyone expects, because attachments, forwarded messages and phone-taken orders all get remembered as email. And the long requests are disproportionately the valuable ones — a forty-line re-order from a repeat customer is worth more than a three-line enquiry from a stranger, and it is the one that falls outside.

Count them by value as well as by number. The two answers are frequently different, and the second one is the one that decides whether any of this is worth doing.

About Cognilium Cognilium builds AI systems that work in tandem with Microsoft Dynamics 365 — the decisions the ERP records but does not make. Business Central and Finance & Operations, on your own governed stack. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Want help sorting a real week of your inbound into the two piles? Book a 15-minute call and bring the week. No deck.

Sales Order Agent or a companion quoting workspace — which request goes where?