TL;DR
Microsoft's agent never contacts a supplier. It computes a promised date from capable-to-promise setup, so it is only as good as the lead-time fields behind it.
Microsoft's agent does not contact suppliers at all. It answers the delivery-date question a different way: by calculating one from configuration already in Business Central. That is a much narrower thing than chasing, and the difference decides whether the date on your quote is a promise or an arithmetic result.
For a distributor who does not hold stock, this is the whole quote.
Can the agent email a supplier?
No — and the boundary is drawn in two places rather than one.
Its document scope excludes the purchase side. The FAQ states the agent "can't create or work with other sales documents (such as blank orders, invoices, or credit memos) or documents in other areas of the product (such as purchase or service orders)."
And its mailbox is inbound from customers. The agent monitors "a designated mailbox for incoming customer emails about item inquiries", and its dispatcher "triggers the agent to perform tasks and then sends results, such as prepared sales quotes or orders, to the customer in response."
A supplier is neither a document type it holds nor a party in that loop. Searched to establish this: the Sales Order Agent overview, the FAQ, and the item-availability page — the three pages that between them define the agent's scope, mailbox and availability behaviour. None describes outbound supplier contact of any kind.
So the honest framing is not that supplier follow-up fails. It is that supplier follow-up is not in the design, and a delivery date gets produced without it.
Then where does the delivery date come from?
From capable-to-promise, and Microsoft is specific about what that means:
"The Sales Order Agent includes an option to use Business Central's capable-to-promise (CTP) functionality that lets the agent calculate the earliest possible delivery date for items not currently in stock."
Note the scope: items not currently in stock — precisely the non-stocking distributor's entire catalogue. Microsoft continues:
"CTP evaluates production capacity, procurement timelines, and supply chain constraints to determine when an item can realistically be delivered. This capability applies even when items aren't currently in stock and must be produced or procured based on lead times, not just inventory."
The load-bearing phrase is "based on lead times". The date is derived, not confirmed. Nobody at the supplier was asked.
What does the calculation actually read?
Four inputs, all of them configuration. Microsoft names them, and says the logic "is based in part on the configuration defined in the Order Promising Setup page":
| Parameter | What it contributes |
|---|---|
| Work Date | "the current work date as the starting point for all delivery calculations" |
| Order Promising Setup Offset (Time) | "how far into the future Business Central should look before issuing a new purchase, production, or transfer order" |
| Inventory Setup Safety Lead Time | "accounts for internal delays like picking, packing, and labeling" |
| Item Lead Time Calculation | "the time required to procure, produce, or transfer the item when it isn't in stock" |
Three of the four are static settings, and the fourth is a field on the item card. None of them observes a supplier. The calculation is honest arithmetic over whatever those fields say.
Microsoft's own worked example makes the mechanism clear: a customer requests ten units, six are in stock or on scheduled orders, and "CTP determines when the remaining four units can be produced or sourced."
What happens when the lead-time field is stale?
The quote is confidently wrong, and nothing in the run signals it.
This is our reading rather than Microsoft's, and it follows from the section above: if the promise is computed from Item Lead Time Calculation, then the accuracy of every promised date is the accuracy of that field.
A supplier who has quietly moved from two weeks to five does not change the field. The calculation keeps returning the old answer, in a well-formatted email, with a date the customer will plan around.
For a non-stocking distributor this is the highest-consequence field in the system, and it is usually the least maintained — it is master data nobody revisits, doing work everybody assumes came from somewhere more current.
The same shape as a quantity that arrives wrong: the document is structurally perfect, so review slides over it.
Does the customer get told the date?
Yes, directly: "The agent creates and sends an email response to the customer that includes the promised shipment dates for items."
Which raises the stake on the previous section. The derived date does not sit in an internal field awaiting confirmation — it goes out, in writing, to the person deciding whether to order. As with every outbound message, a reviewer approves it first; what the reviewer sees is a plausible date with no indication of how it was reached.
What would actually chasing a supplier require?
A second surface, and it is worth being precise about the shape because it is a common request.
Chasing means outbound contact to a party that is not the customer, on documents the quoting agent does not hold, with replies that arrive unstructured and have to be read back onto a line. Three things follow:
- A different mailbox and a different identity. The quoting agent's identity resolution is built around matching an inbound sender to a customer contact, which is the wrong instrument for supplier correspondence.
- A different permission surface. Purchase documents are outside what the quoting agent may hold at all, so this is a separate account with its own permission sets rather than a wider grant on the same one.
- A written-back date with its provenance attached. A date a supplier confirmed and a date a formula produced should never look identical on a quote, and on Business Central's own promising path they would.
That third point is the one to design for even if you never build the chasing. Marking how a date was reached costs a field and turns an invisible assumption into something a reviewer can check.
If you quote items you do not hold, the delivery date is the promise that costs you. Book a 15-minute call — bring a recent quote and the lead-time fields behind it, and we will show you where the date actually came from.
Sources
This article is part of our work on the RFQ quoting engine.
Share this article
Engineering Quote Automation
Topic Cluster
How an agent reads an RFQ, matches each line to your catalogue and prices it, and what has to happen to the lines it cannot resolve.
