Short answer: there are four ways to connect AI to Business Central, and the choice is driven less by technology than by how open-ended the list of questions needs to be. What they share is that the integration runs under a Business Central identity — and that identity, not the model, is the boundary of what the AI can see and do.
Four routes, briefly
| Route | When it fits | What it needs |
|---|---|---|
| Built-in Copilot | Scenarios already in the product | Switch on and configure |
| Power Automate with AI Builder | Fixed process with one model step | Licensing, connector |
| Custom integration over the API | A narrow set of known questions | Development, app registration |
| An MCP layer | Agents and a growing capability list | Development, server, hosting |
The first two need no development and are worth testing first. The third and fourth are projects; the difference between them is covered in the MCP server guide.
Worth naming what is not on this list. Exporting data into a separate store "so the AI has something to query" is a common idea and almost always wrong for an ERP: you end up with a second version of the truth that goes stale, and every question about whether a figure is current comes back.
What the Business Central API actually is
Three different things hide behind the phrase, and confusing them costs time at the start.
- The standard REST API — ready endpoints for the main entities: customers, vendors, items, orders, invoices. Covers most typical requests and needs no development on the Business Central side.
- OData through web services — publishing an arbitrary page or query as a service. More flexible, but each endpoint has to be published deliberately, and performance depends on what you published.
- Custom API pages in AL — when you need fields from your extensions or a specific data shape. This is customisation, though small.
A practical rule: start with the standard API, and publish separately only what it does not provide. The reverse order produces dozens of endpoints that nobody maintains afterwards.
Authentication: whose identity it runs as
This is the main architectural decision, and it has to be made at the start because everything downstream depends on it.
Service account
The integration runs under a single technical identity with a fixed permission set. Simple to implement. The consequence: every user sees the same slice of data. If a sales director and a finance director must see different things, this does not fit.
Delegated access
The integration acts on behalf of whoever is asking. Each person sees exactly what Business Central permits them to see, and the log shows the real person. Harder to build, and for most companies the right choice — switching later is a rebuild, not a configuration change.
Both are built on Microsoft Entra ID. App registration, Business Central permissions and admin consent are a standard procedure, but they need somebody with tenant admin rights, and that is worth arranging before work starts rather than on the last day.
Permissions
The integration's identity is an ordinary Business Central identity. It gets a permission set, and the platform refuses anything outside it exactly as it would for a person. Three things worth doing deliberately:
- A separate permission set for the integration, not a copy of an accountant's role "to be safe". Excess rights never get narrowed later.
- Company scope. If there are several legal entities, state which the integration may reach.
- A separate identity per agent if there will be more than one — otherwise the change log cannot answer who did what.
Wider context: security, permissions and data residency.
Limits and pitfalls
- Request throttling. Cloud Business Central limits call intensity. An assistant making forty small calls per question hits that quickly. The fix is operation design: one call returning what is needed rather than twenty returning fragments.
- A sandbox is not production. Data volumes differ, and a query that is instant in a sandbox can hit a timeout in production — which the agent may interpret as "no data". Test against realistic volumes.
- Updates twice a year. Integrations on the standard API survive releases the way AL extensions do: they need checking after each major update, not rebuilding. Anything reading undocumented internals does not survive, which is the reason to stay on published endpoints.
- Environments. Keys, URLs and permissions differ between sandbox and production. Obvious until somebody deploys sandbox configuration into production.
The order of work
- Check whether built-in Copilot already covers the question. Cheapest possible answer.
- Define the specific questions and who will be asking them.
- Check which data is available in the standard API and what will need publishing.
- Choose the authentication model: service account or delegated access.
- Create a separate permission set for the integration.
- Build a prototype in a sandbox and give it to the people who will ask the questions.
- Verify answers against the same questions computed by hand.
- Verify that the system refuses what it should refuse.
- Go to production with the permitted scope written down.
Steps 7 and 8 are the ones most often skipped, and they determine whether the solution is still in use six months later.
What you can do yourself
| Part | In-house? |
|---|---|
| Switch on and evaluate Copilot | Yes, configuration only |
| A Power Automate scenario with AI Builder | Yes, with someone who knows flows |
| App registration in Entra ID | Yes, standard procedure |
| A separate permission set | Yes, if you know your rights model |
| A narrow assistant on direct API calls | Yes, with an integration developer |
| Defining calculations and terms | Only you — no vendor decides this |
| An MCP layer with an operation catalogue | Rarely: needs BC data model knowledge |
| Testing refusals and edge cases | Hard without a list of other people's mistakes |
The top four rows are worth attempting before talking to any vendor: they cost nothing and give you a factual picture of what is missing. The bottom three are what you actually pay for.
Indicative pricing: discovery from $750, assistant from $3,000, agent from $6,000. Model usage and hosting are separate running costs. Detail: how much AI for Business Central costs.
Frequently asked questions
Do we need to export data into a separate store?
Almost never. The assistant queries Business Central at the moment the question is asked, so the data is always current. A separate copy creates a second version of the truth that goes stale and reopens every question about which figure to believe.
Who has to grant access in Entra ID?
Someone with tenant administrator rights: app registration, Business Central permissions and admin consent. About half an hour of work, but it needs arranging before development starts — waiting for that person is the most common cause of delay.
How many API calls does this generate?
It depends on design. A poorly designed assistant makes dozens of small calls per question and hits throttling quickly. The right approach is operations that return what is needed in one call.
What happens after a Business Central update?
Integrations on the standard API survive releases but need checking after each major update, like AL extensions. Build that into support rather than hoping it will be fine.
Can we connect anything without development?
Yes, two ways: switch on Copilot, or build a scenario in Power Automate with AI Builder. Both are limited to what the product anticipated, and both are worth trying first because they cost less than any development.