TL;DR
The message that changes something is almost always the second one. A correction names a product and a quantity, so every product test fires on it — and applying it as an order line is how a customer's change disappears while the quote still looks right.
Why does a correction in a follow-up email get lost?
Because the system read the first message and the customer changed their mind in the second one.
That sounds like a bug nobody would ship. It is close to the default behaviour of anything built around a request rather than a conversation — a request arrives, gets processed, produces a quote. The follow-up two hours later saying the insulation is no longer needed is a new request by that model, and a new request that contains no order lines produces nothing at all.
The correction was visible in the mailbox the whole time. It was invisible everywhere it mattered.
For anyone specifying how a quoting system should read a thread. 6 minute read.
The unit of work is the thread, not the message
The first fix is structural and it is not optional: the whole conversation is read, every time, including everything that arrived after the original request.
That has consequences beyond re-reading. If message three modifies message one, then the state of the quote depends on the order the messages are processed in, which means:
- Corrections are ordered first, ahead of the original lines, because they change how those lines are read.
- Each one is marked with the message it came from, so a reviewer can see that this instruction is not part of the original request.
- Re-reading is idempotent. Processing the thread twice must not apply the same change twice — which is a real risk once a system is re-reading everything on every new message.
That third point is the one that bites in build. A correction applied twice is a quantity halved twice.
A correction fires every product test you could write
Here is why this is genuinely difficult rather than merely fiddly.
"Sorry, make the pipe insulation four boxes, not two."
Count what a product-detector sees in that sentence: a product name, and two quantities. It looks more like an order line than most order lines do. Every heuristic worth having will fire on it.
But it does not order something. It changes something — and the difference is invisible to anything looking for products. Filed as a product, it becomes an additional line on the quote for four boxes of insulation, sitting underneath the original two, and the total is now wrong in a way that reads as perfectly normal.
The second shape is worse because it looks harmless:
"Actually scrap the pipe insulation, we have enough on site."
A product name and a quantity of nothing. Filed as a product it matches, finds no quantity, and either drops out silently or arrives as a line with a blank where a number should be — chapter 7 is about what blanks do to a total.
This is the most expensive mistake available in quoting, and the reason is not the money. It is that the quote still looks right. Nobody rechecks a document that looks finished.
So never apply a correction automatically
This is our position rather than a documented fact, and it is worth stating plainly because it runs against the instinct to be helpful.
A correction is surfaced at the top of the screen, and a person acts on it. The system does not apply it.
The reason is that "scrap the insulation" is unambiguous to a human and genuinely ambiguous to software. Which line — there may be two insulation rows at different specifications. By how much — all of it, or the quantity they now have on site? "Four boxes, not two" is clearer, and still: is that four in total, or four more?
Being confidently wrong about a change the customer explicitly asked for is the worst available outcome, considerably worse than pausing for ten seconds of human attention. The correct behaviour is to make the change impossible to miss and cheap to apply, not to guess at it.
Microsoft runs multiturn conversations, and documents where they strain
Business Central's Sales Order Agent [GA] handles follow-ups by design. Microsoft:
"If important details are missing or more choices are available, the agent engages in multiturn email conversations to clarify the request."
And it maintains the link between conversation and document: "If the customer decides to update the quote by sending another email listing required changes, the agent assists with these changes by locating the quote and making the requested updates."
Microsoft also publishes where this gets unreliable, which is the useful part. From its Scenarios impacting reliability section:
"Reliability decreases if you significantly change the email the agent drafts about item availability before sending it to the customer. This issue is more apparent when the external customer follows up with an email using pronouns like "them" or "it" and other words instead of repeating specific quantities and names. For example, the customer replies, "I want them all.""
That is the correction problem in its purest form. "I want them all" contains no product and no quantity, and it is only resolvable against what was said in the previous message — which is exactly why the thread rather than the message has to be the unit of work.
The window closes when the quote becomes an order
There is a hard boundary here worth planning around, and Microsoft states it plainly:
"Based on more customer requests, the agent can make changes to the sales quotes, but not to the sales orders."
So corrections are handled while the document is a quote, and stop being handled the moment it converts. After that the change is a manual edit by a person who has to notice it is needed.
That is a sensible boundary — an order has downstream effects a quote does not, which chapter 10 covers — but it means the value of catching a correction early is not evenly distributed. A correction caught before the quote goes out costs nothing. The same correction caught after conversion costs somebody's afternoon.
What the reviewer has to be able to see
Two things, and both are about provenance rather than cleverness.
Which message each instruction came from. An instruction from a follow-up is a different fact from one in the original request, and collapsing them into a single list of customer instructions throws away the thing that makes a reviewer look twice.
Both directions of the conversation, in one place. A question we asked and the answer that came back belong against the line they concern, not in somebody's mail client. Otherwise an incomplete line is a dead end — the system knows what it needs and has nowhere to go for it.
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 to see how a real thread of yours would be read, corrections and all? Book a 15-minute call and bring one. No deck.
Sources
- Sales Order Agent overview — Business Central
- Process sales quotes and orders with Sales Order Agent
- FAQ for Sales Order Agent — Business Central
Sources
Share this article
The workspace these articles describe — one queue, per-line confidence, supplier choice and the write-back — as a product for Business Central distributors.
