What can a quoting agent read and write in Business Central?

It reads and writes as a user — a named one, with its own account. Not through an API, not through an integration layer with a service principal. Microsoft's Sales Order Agent holds permission sets and a profile like any employee, and everything it touches carries its user ID.

That single design choice answers most permission questions before they are asked, because the answer is almost always "the same way it works for a person."

How does the agent get access to anything?

Through the two mechanisms Business Central already uses, and the split between them matters:

"The agent operates within the permissions and profile (role) assigned to it by the administrator. Permissions define which areas of the product (tables) the agent has access to. The profile outlines the UX elements (pages and actions) the agent can engage with during its work."

Permission sets govern data. The profile governs surface. A table the agent may read is still unreachable if no page in its profile exposes it — which is a tighter arrangement than a data-level grant on its own, because it constrains not just what the agent may see but where it may go.

That is deliberate, because the agent works the way a person does:

"Conceptually, the agent interacts with Business Central functionality in a manner similar to how Business Central users interact with it."

It "navigates pages, invokes UI actions, and enters data as a user would." And Microsoft is candid that the route is not fixed in advance: "The agent's interaction surface and steps aren't hardcoded; instead, AI determines them based on the context of each step."

So the permission set is the boundary, not the script. You are not enumerating allowed operations. You are fencing a user and letting it find its way inside the fence — which is why the fence, rather than the instructions, is the thing to get right.

What is it actually allowed to write?

A deliberately narrow surface. Two document types, and one of them stops being editable:

"The agent is designed to work with sales quotes and sales orders. 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)."

Then the asymmetry, which is the sharpest line in the section:

"Based on more customer requests, the agent can make changes to the sales quotes, but not to the sales orders."

The quote is a working document; the order is settled. Once the conversation has produced an order, further customer emails cannot walk it backwards through the agent. A person does that.

This is also why the quote comes first even when nobody asked for one. Microsoft notes the agent "always creates a sales quote as the first step, even when the customer asks for an order", because quotes "have no impact on planning, reservations, availability calculations, or cash flow forecasts." The write surface was chosen for how little it disturbs.

What can it never create?

Master data, and this is the boundary most people expect to be softer than it is:

"The agent doesn't create new items, contacts, or customers. It only works with the entities that are already registered in Business Central. The agent is designed to ask a human user to provide additional information or perform the task manually, when it can't find this data in Business Central."

Read the second half as the design position it is. The agent's response to missing data is to ask, not to invent — the same instinct that governs an unresolved quote line.

And nothing it produces reaches the ledger: "The agent doesn't post documents." Every financial consequence stays behind a human action.

Together those two make the blast radius small. An agent that creates no master data and posts nothing can produce a wrong document, and a wrong document is recoverable.

Which line types does it understand?

One. This is the constraint most likely to bite a distributor, and it is stated plainly:

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

Charge (Item) is the one to notice. That is where freight and handling live on a Business Central sales document. A quote that needs a delivery charge on it needs a person to add the line.

Two further limits sit alongside it. On variants: "the use of the item's Variant Code isn't currently supported. It leaves the Variant Code field empty." An empty variant on a line whose description mentions a colour is a quote that looks complete and is not.

And on size: "At this stage, the agent supports the creation of up to 15 item lines per sales document. Increasing the number of lines might result in lower-quality output." Microsoft's phrasing is worth keeping — the ceiling degrades quality rather than throwing an error.

How do you tell what the agent did rather than a person?

By the user ID, everywhere, with no separate audit surface to consult:

"All actions done by the agent, including creating and modifying records and calling actions, carry the agent's user ID. This user ID appears in the same places and in the same way as it does with other users, such as in list views, history, posted documents, notifications, and more."

That is the payoff of the runs-as-a-user design. Attribution is not a feature anyone had to build for the agent; it inherits the one the ERP already had.

The same inheritance applies to control. Approval workflows "can be used to add an extra layer of control to the tasks done by the agent, as they do with other users" — so releasing a quote can require a second party without anything agent-specific being configured.

What changes if your Business Central is extended?

The permissions have to follow the extensions, and Microsoft says so directly:

"If customizations or ISV solutions modify the pages or business logic the agent uses, such as item, contact, and customer cards and lists, or sales quotes and orders, assign the required extension permission sets to the agent account."

Miss that and the agent hits a surface it cannot reach on a page it is expected to use. Microsoft's standing advice is to start from the shipped sets: it "strongly encourage[s] using the permission sets and the profile included with the Sales Order Agent."

There is one further boundary worth knowing before planning around it. "Currently, partners can't extend this capability." What is available instead is visibility — the agent's prompt instructions "are included in the Sales Order Agent source code on GitHub", and "Partners can review these prompts to understand how the agent evaluates messages and matches items."

You can read how it decides. You cannot change how it decides. That distinction is the whole of the build-or-adopt question.

If the question in front of you is what an agent should be allowed to touch, that is a permissions conversation before it is an AI one. Book a 15-minute call — bring your quote-to-order process and who signs off on what, and we will map what an agent could hold.

Sources

• FAQ for Sales Order Agent — Business Central
• Sales Order Agent overview — Business Central
• Set up Sales Order Agent — Business Central

This article is part of our work on the RFQ quoting engine.