Back to Blog
Published:
Last Updated:
Fresh Content
AI Quoting for Business CentralChapter 10

What should an AI system write back into Business Central, and what should it never touch?

6 min read
1,431 words
high priority
Ali Ahmed

Ali Ahmed

AI Solutions Engineer, Cognilium AI

TL;DR

Three writes are worth having: the quote, the customer's own names for your products, and a new customer record. Stock quantities, financial postings and records it did not create are the line — and volunteering that line is what makes the access conversation short.

What should an AI system write back into Business Central, and what should it never touch?

The instinct on a first technical call is to be modest about writing. Read-only sounds safe, sounds humble, and gets you through the conversation.

It is also the wrong answer, because the two most valuable things a quoting system produces are things the ERP should own: the quote itself, and what was learned while making it. Keep them outside and the distributor is renting their own data back.

The right answer is narrower and stronger: write a short, specific list, and say out loud what you will never touch.

For the Business Central partner or IT contact who has to approve this. 7 minute read.

Three writes worth having, and the case for each

The quote, as a real Business Central sales quote. Not a PDF generated elsewhere and filed. If the quote lives in the ERP, then follow-up, reporting and conversion to an order all work the way they already work, with no new process and no second system to reconcile.

The customer's own names for your products. When a reviewer confirms that "those valves" means a specific item for this specific customer, that confirmation belongs in Business Central's item reference table — a standard table, against that customer.

A new customer record, when a first-time enquiry turns into real business. So the relationship starts in their system rather than in ours.

That is the whole list. Everything else a quoting system knows is working state and can stay where it is.

The line, and say it before anyone asks for it

It does not write stock quantities. It does not post anything financial. It does not touch a record it did not create.

Say that sentence early, unprompted, in the first technical conversation.

It is worth more than any certification for one reason: it is checkable. A partner can verify it against the permission set in an afternoon, which is not true of most assurances anyone offers them.

And it costs nothing, which is the part people miss. Nothing in the workflow needs the permissions it declines. Stock moves when a quote becomes an order and Business Central posts it, through exactly the path it always did. There is no capability being given up here — only a set of permissions that would have to be justified and never needed justifying.

Microsoft drew the same line, and published its reasoning

This is not a cautious ISV being timid. It is the boundary Microsoft's own Sales Order Agent [GA] observes, and the reasoning it gives is the clearest statement of the principle available:

"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."

A quote is the safe document because nothing downstream depends on it. That is precisely why it is the right thing for a system to create, and why creating anything further is a different conversation.

Microsoft is explicit about the rest:

  • "The agent doesn't post documents."
  • "It 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)."
  • "The agent is designed to work with sales lines of type "Item"; other sales line types, such as Resource, Charge (Item), Allocation Account, and Fixed Asset, aren't supported."

And on one point Microsoft is more conservative than the list above: "The agent doesn't create new items, contacts, or customers. It only works with the entities that are already registered in Business Central." A first-time enquiry becoming a customer is a human step in its model.

Both positions are defensible. The point for anyone evaluating either is that the boundary is published, which is what makes it possible to check.

The write that compounds, and why the table is usually empty

Of the three, the item reference is the one that changes the economics over time.

Every confirmed match — this customer's words mean this item — makes the next request from that customer resolve without a person. The share of lines needing review falls month by month, and it falls per customer, because the learning is about a relationship rather than about products in general.

Two things make this the strongest thing to say in a commercial conversation:

It is their table, not ours. Item references are standard Business Central. A partner already knows what they are and already supports them. Nothing proprietary is being introduced.

It keeps working whether or not they keep paying us. That is the opposite of lock-in, and it is a sentence very few vendors can say honestly.

The table is nearly always empty when we arrive, and that is worth understanding correctly. Business Central has always had the capability. What it never had was anyone able to afford the typing — somebody would have to sit and enter customer-specific names forever. We are not adding a feature; we are populating one that has been there all along.

One rule that is absolute, and it is about a different kind of boundary: what one distributor's customers call their parts is that distributor's commercial data, and it is never pooled across distributors. Pooling it would be the fastest way to lose every account at once.

An open question we are not going to fake

Does Microsoft's agent write item references back?

We do not know, and the documentation we have read does not say. Here is exactly what is established and where it stops.

The agent reads them: Item Reference is one of the eight tables its item search covers, with Reference No. and Description among the fields. That is documented.

Whether it creates new ones is not addressed. The nearest statement is "The agent doesn't create new items, contacts, or customers" — and an item reference is none of those three things. It is reasonable to read that sentence as implying no write-back, and reading it that way would be an inference, not a fact.

This matters commercially, because the write-back is the strongest ownership argument in the category. We are recording it as unresolved rather than asserting the convenient answer, and the way to settle it is a sandbox test, not a closer reading.

Identity and permissions, inside the ERP's own model

A detail worth raising early with a partner, because it answers the question they are about to ask.

Microsoft's agent runs as a first-class Business Central user with its own permissions: "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) that limits the parts of the product and UI elements (such as pages, fields, and actions) it can access."

And its work is attributable: "All actions done by the agent, including creating and modifying records and calling actions, carry the agent's user ID." Approval workflows apply to it as they do to anyone else.

That is the model to match. Anything writing into an ERP should be a named actor with a scoped permission set, whose changes are attributable after the fact. A shared service account that writes as "the integration" is the thing a partner is right to refuse.

A switch, not a requirement

Last point, and it removes the objection before it arrives.

A distributor who will not grant write access still gets the product. Confirmations are kept in our own records instead, matching still improves for them inside the workspace, and they get an export they can review and import themselves.

Write-back is how the value compounds in their system. It is not the price of entry, and treating it as one turns a five-minute permissions conversation into a reason not to start.

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 the boundary conversation in one call, with your partner on the line? Book a 15-minute call and we will walk exactly what is read and what is written. No deck.

Sources

Sources

Share this article

The work behind this series

The workspace these articles describe — one queue, per-line confidence, supplier choice and the write-back — as a product for Business Central distributors.

Ali Ahmed

Ali Ahmed

AI Solutions Engineer, Cognilium AI

Ali Ahmed is an AI Solutions Engineer at Cognilium AI.

Applied AI AgentsAgentic SystemsRetrieval-Augmented Generation (RAG)LLM Product Engineering
Next in this series
What does Business Central's Sales Order Agent not do?
Chapter 11 · 6 min
In short

Key takeaways

  • Three writes are worth having: the quote as a real Business Central sales quote, the customer's own names for your products, and a customer record when a first-time enquiry becomes real business.
  • Say the boundary before anyone asks — no stock quantities, no financial postings, no record it did not create. It is worth more than a certification because a partner can check it.
  • Nothing in the workflow needs the permissions it declines. Stock moves when the quote becomes an order, and the ERP posts it exactly as it always did.
  • Microsoft's own agent creates a quote first because a quote is the safe document — nothing downstream depends on it — and it does not post documents at all.
  • Learned customer names belong in the ERP's own standard table, so they keep working whether or not the distributor keeps paying anyone.
What goes wrong

Common mistakes to avoid

  • Going read-only to sound safe. The quote and what was learned making it are exactly the things the ERP should own.
  • Waiting to be asked about permissions. Volunteering the boundary is what makes the access conversation short.
  • Writing as an anonymous service account. Anything touching an ERP should be a named actor with scoped permissions and attributable changes.
  • Making write-back the price of entry, or pooling what it learns. It should be a switch — and one distributor's customer part names are their commercial advantage, never a shared corpus.

Still have a question this did not answer?

The person who wrote this article answers these. Describe your setup and what you are stuck on — you will get a straight answer, including where we think the approach is wrong.