AdvancedMicrosoft Dynamics 365 Business Central (on-premises)API v2.0 / OData / AL / Permissions

Adding a Private AI Layer to Business Central On-Premises

Question
how to add AI to Business Central on-premises

Also searched as

  • Business Central on-prem AI without cloud
  • Business Central on-premises local LLM
  • Business Central API v2.0 chatbot private
  • Business Central on-prem Copilot alternative

Short answer

Business Central on-premises has a clean, supported read path: API v2.0, custom API pages written in AL, and OData web services, all enforcing the calling user's permissions. Put a tool server on top of those, add a retrieval index and an open-weight model on your own GPUs, and keep write-back behind human approval and the same APIs.

Applies to: Business Central on-premises (versions 14 and later, wave releases) with the Business Central Server instance reachable from the tool server

How to stand up a private AI layer on Business Central

  1. 1Decide the first questions: item availability, open sales and purchase lines, customer and vendor ledger balances, production orders, approvals.
  2. 2Choose the access path per question: API v2.0 for standard entities, a custom API page in AL for anything missing, and a SQL replica only for broad aggregates.
  3. 3Configure authentication on the server instance and create a service identity with a minimal permission set, or delegate the user's identity from the tool server.
  4. 4Publish the web services or API pages you need and test with a low-privilege user to confirm the permission behaviour.
  5. 5Index attachments, item and customer notes and external documents in a local retrieval store; refresh incrementally using modified-at filters.
  6. 6Wrap the endpoints in a tool server (MCP) with parameter validation, row limits and an audit log.
  7. 7Serve an open-weight model with vLLM or Ollama on local GPUs and pilot read-only questions before drafts.

Real data access paths in Business Central

The standard API v2.0 exposes entities such as customers, vendors, items, salesOrders, salesInvoices, purchaseOrders and generalLedgerEntries under a companies path, and supports OData query options like $filter, $select, $expand and $top. Custom API pages written in AL let you expose any table with your own API publisher and group, and OData web services can publish pages and queries. The server instance exposes OData and API endpoints on configured ports, with Windows, NavUserPassword or Azure AD based authentication depending on how you set up the instance.

The database is SQL Server, with tables named per company and suffixed with the app id, for example [CRONUS International Ltd_$Item$<app guid>]. Direct SQL is possible on a replica but unsupported for logic, and FlowFields and calculated values are not stored. Use APIs for anything that must match what users see, and SQL only for bulk aggregates that you validate against the application.

GET https://bc-srv:7048/BC/api/v2.0/companies(<company-id>)/salesOrders?$filter=status eq 'Open'&$select=number,customerNumber,orderDate,totalAmountIncludingTax&$top=50
Authorization: Basic <web service access key>   (or Windows / OAuth2 as configured)

Reference architecture and air-gapped option

Run the tool server next to the Business Central server instance, with a read-only SQL replica for aggregates, a retrieval index for documents and an open-weight model on local GPUs. A change feed using the modified-at fields in the API or SQL change tracking keeps the index current. Every question, tool call, endpoint and answer is written to an audit log.

For an air-gapped deployment, the same components run on an isolated network with models and packages brought in by controlled transfer. Microsoft's own Copilot features for Business Central are delivered through the cloud service, so check current availability for on-premises; a private layer is the practical route when data cannot leave your network.

Permissions and write-back

Business Central permissions are sets assigned to users and user groups, evaluated at the object level (tables, pages, codeunits, queries) and can be extended with security filters. API and web service calls run under the identity of the caller, so delegating the user identity gives you true permission mirroring. If you use a single service identity for simplicity, you must enforce filters in the tool server and accept that it is more error-prone.

Write-back uses the same APIs: the assistant drafts a sales quote or purchase order, a person approves, and the tool server POSTs to the API so validation, number series and workflow run. Keep write scopes narrow, record the approver in the audit log, and never use SQL for writes.

Sizing, rollout and honest limits

A 50 to 250 user Business Central site usually needs one inference GPU for an 8B to 32B class model, plus a small server for the tool server and index. Attachment and document indexes commonly fall in the low gigabytes to low tens of gigabytes. Phase one is read-only questions, phase two is drafts for review, phase three is a few approved actions through the API.

Honest limits: API rate limits and server resources apply, so batch heavy reads through the replica. Custom AL logic is reachable only if you expose it. If your needs are met by built-in reports, Power BI and standard search, a language model adds operating cost. And if cloud is acceptable for some data, Microsoft's own services may be simpler for that scope.

Try it here, free

Business Central On-Prem Private AI Layer Blueprint Generator

Open full tool

Describe your Business Central on-prem setup and get an architecture plan for a private AI assistant built on API v2.0 and a local model.

Common pitfalls

  • !Using one broad service identity and forgetting to filter per user, which can expose data a user could not see in the client.
  • !Treating API field names as identical to SQL columns. They are not, and the API applies business rules.
  • !Pulling large sets through the API page by page for aggregates. Use the replica or a custom query API instead.
  • !Skipping TLS and certificate setup on the server instance, then sending credentials in clear text.
  • !Assuming cloud-only Copilot features exist on-premises without checking your version and licence.

How an ERP-grounded AI assistant handles this

A grounded Business Central assistant calls the same APIs your integrations use, shows the request behind each answer and respects the calling user's permission sets. Netray builds the tool server, retrieval index and local model as a private layer in your environment.

Frequently asked questions

Which API should the assistant use first?

Start with API v2.0 for standard entities because it is documented and respects permissions. Add custom API pages in AL for tables and fields the standard API does not expose.

Can we avoid SQL entirely?

For most question types yes. Use SQL on a replica only for large aggregates or full-text scans, and validate results against the application before releasing.

Does this work on Business Central 14?

Yes for read paths in general, but API coverage and authentication options differ by version. Check the documentation for your build and test the endpoints you plan to depend on.

How do we handle upgrades?

Keep the tool server on API contracts rather than internal tables, version your custom API pages, and run an automated question set after each upgrade to catch regressions.

Related

Advanced

Adding a Private AI Layer to Dynamics NAV On-Prem

Dynamics NAV can feed a private AI assistant through two safe doors: a read-only SQL Server copy for analytical questions and published web services (OData and SOAP) for anything that must respect NAV logic and permissions. Put an open-weight model and a retrieval index beside them on your own hardware and keep writes behind human approval and codeunit-based services.

Advanced

Adding a Private AI Layer to Dynamics GP On-Prem

Dynamics GP is an easy system to read from and a delicate one to write to. Read from curated SQL views on a replica of the company database, search documents with a local retrieval index, serve an open-weight model on your own GPU, and send any write through eConnect or another supported integration after a person approves it.

How-to

Calling and extending the Business Central API v2.0

The Business Central API v2.0 is a REST/OData endpoint at api.businesscentral.dynamics.com/v2.0/{tenant}/{environment}/api/v2.0, authenticated with Azure AD OAuth 2.0. It exposes standard entities like customers and items, and lets you publish your own with an AL API page.

Error fix

Fixing "You do not have the following permissions on TableData (table): (permission)" in Business Central AL

This runtime error means the current user's assigned permission sets do not grant the required Insert, Modify, Delete, Read, or Execute right on that specific table. It is most common right after installing or updating a custom AL extension, because Business Central checks object-level permissions even for tables an extension owns.

Error fix

Fixing "Cannot create a record in (table). The record already exists" in D365 F&SCM data entity imports

This is the standard kernel duplicate-key exception, thrown when the Data Management Framework tries to insert a staging row into a target table whose unique or alternate key already matches an existing record. It almost always means the entity's insert-vs-update logic did not recognize the target row as an update, not that you have a true accidental duplicate in your source file.

Error fix

Fixing "There are currently no batch servers available for processing" in D365 F&SCM

This message means the batch framework cannot find any AOS instance flagged as a batch server and available for the batch group the job is assigned to. The fix is almost always in server configuration (System administration > Servers) or batch group assignment, not in the batch job itself.

AI for ERP

AI for Dynamics 365 Business Central, on-premises or SaaS, beyond Copilot

AI for Business Central beyond Copilot: grounded question answering over BC's data via OData and APIs, for on-premises and SaaS tenants alike.

AI for ERP

AI Agents for ERP, Running On-Prem

A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.

Stuck on Microsoft Dynamics 365 Business Central (on-premises)?

Talk to engineers who work inside Microsoft Dynamics 365 Business Central (on-premises) every week, and who build private AI that answers these questions from your own ERP data.

Keep exploring

Free tools

ERP fixes and how-tos

AI on your ERP

Integrations

Comparisons

Software