How to add AI agents to Dynamics 365 Business Central
Short answer
Build agents on top of Business Central's API v2.0, custom API pages and OData web services, expose a small set of narrow tools, and keep a human approval step on every write. Microsoft ships its own Copilot and agent features in SaaS, so the real question is which workflows they do not cover.
Most Business Central shops are small and mid-sized manufacturers and distributors with a lean finance and planning team. The pain is rarely a missing report. It is the repetitive middle work: chasing late purchase orders, reconciling vendor invoices against receipts, re-planning after a planning worksheet run throws 200 action messages, and answering the same where-is-my-order question all day.
An AI agent in this context is not a chatbot. It is a loop that reads Business Central data through a controlled tool layer, decides what to do next, and either reports back or proposes a change that a person approves. Done well it behaves like a junior planner or AP clerk who never writes to the ledger on its own.
Business Central is unusual in that the same product runs as Microsoft-hosted SaaS and as an on-premises or partner-hosted install, with an extension model (AL) that lets you add your own API pages. That shapes everything below: the tool layer, the auth model and where the model itself can run.
What teams use it for
Planning worksheet triage
After a Planning Worksheet or Requisition Worksheet calculation, an agent groups action messages (new, reschedule in, reschedule out, cancel) by vendor and urgency, flags the ones tied to firm planned production orders, and drafts a prioritised list for the planner instead of scrolling hundreds of lines.
Late purchase order expediting
The agent finds purchase lines past Expected Receipt Date, checks open sales demand on the same item, drafts a vendor email with the exact PO and line numbers, and logs the contact on the purchase header as a comment.
Vendor invoice to receipt matching
Compares posted purchase receipts to incoming invoice lines, explains price and quantity variances in plain language, and proposes the purchase invoice or credit memo lines. A person posts it.
Order promising answers
Reads item availability, open production orders and purchase orders to propose a ship date for a sales quote line, with the supply it assumed listed so the salesperson can check it.
Inventory and BOM hygiene
Scans for items with no routing, certified BOMs with inactive components, negative inventory and blocked items still on open orders, then opens a review list rather than fixing anything silently.
Microsoft Dynamics 365 Business Central integration surface
- Standard API v2.0 under /api/v2.0/companies({id}) exposes items, customers, vendors, salesOrders, purchaseOrders, purchaseInvoices, journals and more with OData query options ($filter, $expand, $top). Entity coverage is broad but not complete, and manufacturing entities such as production orders are thinner than sales and purchasing.
- Custom API pages: an AL extension can publish page type API objects with your own APIPublisher, APIGroup and APIVersion, which is the clean way to expose production orders, BOM lines, routing or your own tables to an agent.
- OData V4 and SOAP web services: any page or codeunit can be published via the Web Services page. Useful for older partner solutions and for calling codeunits that carry business logic you do not want to reimplement.
- Webhooks: the API supports subscriptions on supported entities that notify a URL on create, update or delete. Subscriptions expire and must be renewed, so treat them as a trigger hint and reconcile by polling lastModifiedDateTime.
- Auth: SaaS uses Microsoft Entra ID with OAuth 2.0 (client credentials for service-to-service, delegated for user context). On-premises installs may use Windows, NavUserPassword or Entra depending on configuration, and basic auth with web service access keys is deprecated in SaaS.
- Microsoft's own Copilot and agent capabilities (for example sales order and payables style agents) are available in SaaS depending on version and region. Check the current release plan before building something that duplicates them.
How it works
- 1
Pick one workflow with a measurable queue
Late POs, planning worksheet triage or invoice matching. Count the weekly volume and the minutes per item so you know whether an agent is worth building.
- 2
Register an app and scope the identity
In Entra ID register an application, grant it Business Central API access, then add it in Microsoft Entra Applications inside Business Central and give it a dedicated permission set. Start read-only: SUPER is the wrong answer.
- 3
Build the tool layer
Wrap 8 to 15 narrow functions such as get_late_purchase_lines, get_item_availability, get_vendor, create_purchase_comment. Each returns small, typed JSON, not raw OData pages. Add custom API pages for anything the standard API lacks.
- 4
Add the reasoning loop
Use a tool-calling model with a planner prompt, a step limit and a requirement to cite the record numbers it used. Log every tool call and its result.
- 5
Separate propose from commit
Writes go to a staging table or a draft (for example a purchase order in Open status, or a journal batch not yet posted). A person reviews and posts. The agent identity never holds posting permissions.
- 6
Evaluate before go-live
Replay 50 to 100 historical cases against the agent, compare with what your planner actually did, and only then switch on live mode for one team.
Example flows
Late purchase order sweep
Trigger: Scheduled at 07:00 each weekday.
- Agent queries purchaseOrderLines where expected receipt date is before today and outstanding quantity is above zero.
- For each line it pulls open sales and production demand for the item and ranks lines by customer impact.
- It drafts a vendor email per vendor with PO and line numbers and the date needed.
- Buyer reviews drafts in a queue and sends; the agent writes a comment line on the PO.
Result: A buyer reviews a ranked list of a dozen vendors instead of scanning the whole open PO report.
Planning worksheet triage
Trigger: A planner finishes calculating the plan in the Planning Worksheet.
- Agent reads the proposed lines through a custom API page on the planning worksheet table.
- It excludes lines already covered by firm planned orders and groups the rest by vendor and lead time.
- It proposes reschedule or cancel actions with the reason (demand moved, stock above reorder point).
- Planner accepts a batch; the agent never carries out the plan itself.
Result: Hundreds of action messages reduced to a short, explained decision list.
Keeping data on-prem
Business Central on-premises or in a partner-hosted private environment pairs naturally with a locally served open-weight model, because the API endpoint, the agent service and the model can all sit in the same network. Serve the model with vLLM or Ollama on your own GPUs, run the tool layer as a small service on a server that can reach the BC service tier, and keep prompts, retrieved records and logs inside the boundary. For SaaS tenants the data still leaves Microsoft's cloud when you call an external model API, so decide per workflow whether a Microsoft-hosted option, a private cloud model, or a self-hosted model is acceptable for the data involved. Expect on-prem versions to lack some newer API entities and Copilot features, which is another reason to rely on custom API pages.
Security checklist
- Use a dedicated Entra application or service account with a least-privilege permission set, reviewed like any other user.
- Keep agent writes to drafts and staging records. Posting, releasing and approvals stay with named humans.
- Log every tool call with the user, company, record keys and the model output that triggered it, so a posted entry can be traced to its proposal.
- Respect company and dimension boundaries: build the tool layer per company and never let the model choose the company id freely.
- Redact or exclude sensitive fields (bank accounts, salaries on employee tables) at the tool layer, not in the prompt.
Ways to get it done
Microsoft Copilot and agents inside Business Central
Effort: Days of configuration, no code, but limited to what Microsoft ships.
Best when your workflow matches a shipped agent (sales order intake, payables style tasks) and you are on SaaS in a supported region.
Power Automate plus AI Builder or Azure OpenAI flows
Effort: Weeks, mostly by a functional consultant.
Good for linear flows with one decision. Gets awkward for multi-step reasoning and for large result sets.
Custom agent with an AL extension for API pages (in-house or with a partner like Netray)
Effort: Typically several weeks for a first workflow, plus an evaluation period.
Right when you need manufacturing entities, on-prem models, or approval flows that match your own process.
Pitfalls
- !Giving the agent a broad permission set during testing and never narrowing it before production.
- !Pulling whole entities through the API and letting the model filter them. Filter server side with $filter and $select to avoid throttling and token waste.
- !Relying on webhooks alone. Subscriptions expire and notifications can be missed, so always reconcile by timestamp.
- !Ignoring extension upgrades: SaaS monthly updates can change standard API behaviour, so pin API versions and run a smoke test after each wave.
- !Posting automatically because it worked in the sandbox. Real vendors send weird invoices.
Frequently asked questions
Can I build AI agents on Business Central without writing AL code?
For read workflows on standard entities, yes: the API v2.0 and OData web services are enough. You need AL only when you must expose manufacturing tables, planning data or custom fields that the standard API does not publish, or add logic that should run inside the service tier.
Does Business Central have its own AI agents?
Microsoft has been adding Copilot features and agent-style capabilities to SaaS, with availability varying by release wave and region. They are worth trying first. Build your own when your process is specific, when you are on-premises, or when data cannot go to the model Microsoft uses.
How do I stop an agent from posting something wrong?
Do not give it posting rights. Have it create drafts, comments or journal lines in an unposted batch, and require a named user to review and post. Add logging so each draft links back to the reasoning and records behind it.
Can this run with Business Central on-premises?
Yes. The API and OData endpoints exist on-premises, though some newer entities depend on the version. The agent service and an open-weight model can run inside your network, so no data leaves. Test which API entities your build exposes before designing tools.
How many tools should an agent have?
Start with a dozen or fewer narrow tools. More tools make the model pick the wrong one more often and make permission review harder. Add tools only when an evaluation case fails for a specific missing capability.
More for Microsoft Dynamics 365 Business Central
Want AI agents working on your Microsoft Dynamics 365 Business Central?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment