Building AI into Business Central: Azure OpenAI and Custom Agents

Microsoft ships Copilot inside Business Central, and for a growing set of tasks that built-in assistant is genuinely useful. It drafts marketing text, suggests bank reconciliation matches, and helps with number-series and field mapping during data entry. But sooner or later a real business hits the edge of what the packaged Copilot does. You want AI that understands your specific chart of accounts, your service contracts, your maintenance history, your naming conventions, your workflow. That is where you stop being a consumer of Microsoft's AI and start being a builder of your own. This guide is about how you actually do that, at the architecture and capability level, using Azure OpenAI Service, AL extensions, and the newer agent tooling around Copilot Studio, and about the security and cost discipline that has to come with it.

The message up front: building AI into Business Central is not one thing. It ranges from a single AL extension that calls Azure OpenAI for a narrow task, all the way to autonomous agents that take multi-step actions on your behalf. The engineering is very approachable. The hard parts are grounding the model on your real data, governing what it can see and do, controlling the cost, and having the discipline to not build what Microsoft is about to ship for free. Get those four right and custom AI in Business Central is one of the highest-leverage things a mid-market operation can do.

1. Beyond built-in Copilot: when to extend Business Central with your own AI

The first honest question is not "how do I build custom AI" but "do I need to." The built-in Copilot in Business Central covers a genuinely widening set of scenarios out of the box, and Microsoft adds to it every release wave. If your requirement is close to one of those shipped capabilities, the right move is almost always to use what is already there, wait a cycle if needed, and spend your engineering budget somewhere it is scarce. Building custom AI to replicate something Microsoft is about to hand you for free is the most common and most expensive mistake in this whole area.

So when does custom AI actually earn its place? A few patterns come up repeatedly in real implementations. The first is domain specificity: your business has vocabulary, processes and data structures that a general assistant simply does not understand. A facilities operator running maintenance through Business Central wants an assistant that knows what a permit to work is, what an asset criticality rating means, and how its own service level matrix maps to work order priorities. No packaged Copilot ships with that. The second pattern is proprietary data grounding: you want the AI to answer questions and draft content based on your live Business Central records and your document library, not on the model's general training. The third is workflow embedding: you want AI reasoning to sit inside a specific process, reading a record, calling a model, and writing a suggestion or taking an action right where the user works, rather than in a separate chat window. The fourth is the unusual output: summarisation, classification, extraction or drafting that is specific enough to your business that no generic feature will match it.

When one or more of those patterns is genuinely present, and the value is real, custom AI on top of Business Central is the right tool. When none of them is present, you are usually better served by the standard Copilot, a Power Platform low-code approach, or simply waiting. The skill is in telling the difference honestly, and I come back to that in the build-versus-buy section, because it is the section that saves the most money. For the wider picture of where Copilot and AI sit inside Business Central today, the Copilot and AI in Business Central hub is the companion to this deeper build guide.

2. The architecture at a glance (Business Central plus AL extensions plus Azure OpenAI Service)

Before any code, it helps to hold the whole shape in your head, because the pieces are simpler than the marketing makes them sound. A custom AI capability in Business Central is, at its core, three things talking to each other: the Business Central application where the user works and the data lives, an AL extension that carries your custom logic, and Azure OpenAI Service, which is the hosted large language model you call. Everything else is refinement on top of that spine.

Azure OpenAI Service is the important choice on the right of that diagram, and it is worth being precise about why. It is Microsoft's enterprise hosting of OpenAI models, running inside Azure with the compliance, data residency, private networking and identity story that an enterprise needs. When you call it, your prompts and your data are handled under Azure's enterprise terms rather than a consumer API, which matters enormously the moment you are sending real business data into a model. For a Business Central shop that already lives in the Microsoft cloud, using Azure OpenAI rather than a raw public model API is not just a preference, it is the path that keeps identity, billing, networking and governance inside one tenant and one set of controls.

The AL extension in the middle is where your intellectual property lives. AL is the language you already use to extend Business Central, and calling an external AI service is, mechanically, just another outbound HTTP call from AL, which the platform has supported for years. What is newer and more important is the Copilot capability model that Microsoft layers on top, which gives your AI feature a first-class place in the Business Central user experience, with the consent, telemetry and admin controls that a responsible AI feature needs. I come back to that model in section six. The grounding step, the part that fetches your relevant records and documents before the model is called, is the piece that separates a toy from a tool, and it gets its own section next.

3. Calling Azure OpenAI from Business Central

At the mechanical level, calling Azure OpenAI from Business Central is an outbound web request from AL code, and if you have ever integrated Business Central with any REST API you already understand the shape of it. You construct an HTTP request, you send it to an Azure OpenAI endpoint, you authenticate, and you parse a JSON response. There is no magic in the plumbing. Let me describe the moving parts at a conceptual level, deliberately without inventing exact method signatures, because the specifics shift across platform versions and you should always confirm against current Microsoft documentation.

The endpoint is a URL specific to your Azure OpenAI resource and the model deployment you created inside it. In Azure OpenAI you do not just call "the model," you first deploy a named deployment of a chosen model into your resource, and you address that deployment. This matters because it means your capacity, your region, and your version are all things you control and pin, rather than a moving public target. The authentication is either an API key issued by the Azure OpenAI resource or, better, a Microsoft Entra ID token so that the call is authenticated as a managed identity rather than a shared secret. I strongly prefer the identity path for anything production, and I explain why in the security section. The request body carries your prompt, framed as a set of messages with roles (a system message that sets the assistant's behaviour, and user messages that carry the actual task and the grounding data), plus parameters such as the maximum tokens to generate and the temperature that controls how deterministic the output is.

On the Business Central side, Microsoft provides a layer of AL objects intended specifically for AI integration, part of the system application, so that you are not hand-rolling raw HTTP for the common Copilot path. That layer handles the request construction, the authentication wiring, telemetry and the connection to the Copilot capability framework. For simple bespoke calls you can still make a direct HTTP request from AL, but for a real Copilot feature you generally lean on the provided AI modules because they give you the platform integration, the consent handling and the observability for free. Either way, the pattern in your AL is the same: gather the input, build the prompt, call the service, receive the completion, validate it, and never blindly trust the output. That last point is not optional. A language model can return malformed data, hallucinated values, or text that does not match your expected structure, so your AL must treat the response as untrusted input, validate its shape, and fail gracefully when the model returns something you cannot use.

A practitioner caution on keys: it is tempting in a proof of concept to paste an Azure OpenAI API key into an AL setup field and move on. Do not carry that habit into production. Keys leak, keys get committed to source control, keys get shared in chat. Use Entra ID managed identity where the platform supports it, keep any unavoidable secret in a proper secret store rather than a plain setup table, and rotate whatever you must keep. The moment your AI feature is calling a paid, data-exposed service, the credential handling stops being an afterthought and becomes part of the security surface.

4. Grounding AI on your Business Central data

A large language model on its own knows a great deal about the world and nothing at all about your business. It has never seen your customer list, your item ledger, your service contracts or your maintenance history. Ask a raw model "what is the outstanding balance on the Al Reem tower service contract" and it will either refuse or, worse, confidently invent a number. The technique that fixes this is grounding, and specifically the pattern called retrieval augmented generation, or RAG. It is the single most important concept in building useful AI on top of a business system, and it is the difference between an assistant that impresses in a demo and one that is trusted in production.

The idea is straightforward. Before you call the model, you retrieve the specific, relevant facts from Business Central and any connected document store, and you place those facts directly into the prompt as context. The model then answers using the facts you supplied rather than its general training. So the flow becomes: the user asks a question, your AL code interprets it, fetches the actual relevant records from Business Central (the contract, the ledger entries, the open work orders), formats those into the prompt as grounding context, and only then calls Azure OpenAI to compose an answer or draft. The model is doing language and reasoning; your code is doing the authoritative data retrieval. That division of labour is the heart of a trustworthy system.

For structured questions, grounding can be as simple as running the right AL query and injecting the results. For unstructured knowledge, such as answering from a library of policy documents, contracts or manuals, you move to the vector-search flavour of RAG: you break the documents into chunks, use an embeddings model (Azure OpenAI provides embedding endpoints for exactly this) to convert each chunk into a numeric vector, store those vectors, and at query time embed the user's question and retrieve the most similar chunks to feed as context. That retrieval layer can live in Azure services built for it, and the result is an assistant that can answer from your documents while citing the passages it drew on. The engineering here is well established and not exotic, but doing it well, choosing chunk sizes, keeping the index fresh, retrieving the right context and not too much of it, is where the quality of a RAG system is actually won or lost.

Why does grounding matter so much? Because it is what converts a plausible-sounding language model into a reliable business tool, and because it is your control point for accuracy and for security both. You decide what the model is allowed to see. You decide what facts it answers from. You can enforce that it only uses the retrieved context and says "I do not have that information" when the answer is not in what you supplied, rather than filling the gap with invention. Grounding is where correctness, security and trust all converge, which is why I treat it as non-negotiable in any serious build. The craft of writing the prompts that carry that grounding, framing the system message, structuring the context, constraining the output, is a discipline in itself, and I go deeper into it in the practical prompt engineering for ERP consultants guide.

5. Copilot Studio and the shift to AI agents

Everything above describes AI as a smart assist: the user asks, the model answers or suggests, the user decides. The direction of travel across the Microsoft stack is toward something more autonomous, and that is the world of agents. It is worth being careful and honest here, because "agent" is one of the most abused words in the current technology cycle, and because the line between what has shipped and what is still preview or roadmap moves quickly. I will describe the shape of it and flag maturity where I can, and you should always verify current status against Microsoft's own documentation before you plan around it.

The distinction that matters is between an assistant and an agent. An assistant responds to a prompt and hands the result back for a human to act on. An agent is given a goal and works toward it across multiple steps, deciding what to do, calling tools or systems, checking results, and continuing, with varying degrees of human oversight. A semi-autonomous agent proposes actions and waits for a human to approve each one; a more autonomous agent takes a defined set of actions on its own within guardrails and reports back. The value proposition is real: an agent that can read a batch of incoming supplier emails, match them to purchase orders in Business Central, flag the exceptions and draft the responses is doing genuine multi-step work rather than answering a single question.

Copilot Studio is Microsoft's environment for building this kind of custom copilot and agent, in a low-code fashion, connecting to data sources and actions across the Microsoft ecosystem including Business Central through connectors. It is a shipped, generally available product for building custom copilots and topics. On top of that, Microsoft has been introducing autonomous agent capabilities and a set of prebuilt agents that touch Dynamics 365 and Business Central scenarios, and this is exactly the area where you must check maturity carefully: some agent capabilities are generally available, others are in preview, and the specifics change release wave to release wave. My honest advice is to treat the agent story as a rapidly maturing capability rather than a finished platform. Build pilots, learn the tooling, but keep your production commitments on the parts that are shipped and supported, and read any "autonomous agent" claim, including Microsoft's own, with a clear eye on what is preview versus what carries a production support statement.

For a Business Central shop, the practical near-term reality is a spectrum. At the low-code end, Copilot Studio lets you build a custom copilot that answers questions and triggers actions against Business Central without deep AL work. At the pro-code end, AL extensions calling Azure OpenAI give you full control for embedded, bespoke capabilities. Agents sit as the emerging layer that will increasingly blend the two, and the operators who win will be the ones who understand the whole spectrum rather than betting everything on the newest and least proven end of it. For where this is all heading over a longer horizon, the Business Central roadmap for the next decade sets the strategic frame.

6. Building a custom Copilot capability inside Business Central

When you want AI reasoning embedded directly in the Business Central experience, rather than in a separate Copilot Studio bot, you build what Microsoft calls a Copilot capability, and understanding this model is what separates a professional AI feature from a hacked-together HTTP call. A Copilot capability is a registered, first-class AI feature in your extension. You declare it, you give it an identity in the system, and in return the platform gives your feature the surrounding machinery that a responsible AI capability requires: consent and admin controls so a customer can turn the feature on or off, telemetry so its usage and behaviour are observable, and a consistent place in the user interface so the AI experience feels native rather than bolted on.

The typical shape of building one is this. You create an AL extension that registers a Copilot capability. You build a page experience, often using the platform's provided Copilot prompt dialog pattern, so the user interacts with your feature the same way they interact with Microsoft's own Copilot features. Behind that dialog, your AL code does the real work: it gathers the context from the current record and related data, performs the grounding retrieval described earlier, constructs the prompt, calls Azure OpenAI through the platform's AI modules, receives the completion, validates it, and presents a suggestion the user can accept, edit or reject. The generate-review-accept loop is deliberate. For most business scenarios the right design keeps a human in the decision, with the AI proposing and the person disposing, and the Copilot capability model is built around exactly that pattern of a suggestion the user confirms before anything is committed.

There are two design decisions that shape the whole feature. The first is where the AI sits in the workflow: is it a proactive suggestion that appears when the user opens a record, or an action the user invokes when they want help? Proactive is more magical and more expensive, since it calls the model whether or not the user needed it, so I lean toward user-invoked for most cases and reserve proactive for scenarios where the value clearly justifies the cost. The second is how you handle the output: a good capability never writes model output straight into the ledger. It shows the suggestion, lets the human verify it against the grounded facts, and only writes on explicit confirmation, with a log of what the AI proposed and what the human accepted. That audit trail is not bureaucratic overhead, it is what lets you trust, debug and defend an AI feature once it is in real use.

The design principle that keeps you safe: treat the language model as a talented but unreliable assistant whose every output must be checked before it counts. Ground it on your real data so it has the facts, keep a human in the loop for anything consequential, validate the structure of every response in code, and log what was proposed against what was accepted. A Copilot capability built on those four habits is one you can put in front of a finance team with confidence. One that skips them is a liability waiting for the day the model confidently returns the wrong number.

7. Security, identity and data governance

This is the section that separates a prototype from something you can actually run in a business, and it is the section that gets skipped most often. The moment your AI feature is sending real business data to a model and potentially acting on that data, you have created a new security and governance surface, and it has to be treated with the same seriousness as any other part of the Business Central estate. There are a few pillars.

Identity, through Microsoft Entra ID. Every call your AI feature makes should be authenticated as a known identity, and every action it takes should respect the permissions of the user on whose behalf it acts. Using Entra ID managed identity to authenticate to Azure OpenAI, rather than a shared API key, means the call is tied to an identity you control and can audit, revoke and monitor. Just as importantly, an AI agent or capability should never become a way for a user to see or do things their own Business Central permissions would not allow. The AI must operate within the user's permission set, not above it. An assistant that cheerfully retrieves data the asking user is not entitled to see has become a privilege-escalation hole with a friendly face.

Data boundaries and tenant isolation. When you use Azure OpenAI Service, you are operating within your own Azure tenant, under enterprise terms, which is precisely why it is the right choice over a consumer model API for business data. You should still be deliberate about what data crosses the boundary into the model. Grounding gives you that control: you decide exactly which records and which document chunks are placed into a prompt, so you can exclude the sensitive fields that do not need to be there. Data minimisation applies to AI prompts just as it does to any other data flow. Send the model what it needs to do the task and nothing more, both to limit exposure and, as it happens, to reduce cost.

Governance and oversight. Someone has to own the questions of what the AI is allowed to do, what data it may touch, how its outputs are reviewed, and how its behaviour is monitored over time. The Copilot capability model helps by giving you consent controls and telemetry, and Azure API Management can sit in front of your AI calls to enforce rate limits, log every request, and apply policy centrally rather than scattering that logic through your AL. But tooling does not replace ownership. An AI feature without a named owner, a clear policy on acceptable use, and a monitoring routine is an incident waiting to happen. This is not a reason to avoid building; it is a reason to build with the governance in place from day one rather than retrofitted after the first surprise. Because Business Central does not live alone, these controls have to extend across everything it connects to, which is the wider theme of the Business Central and the Microsoft ecosystem guide, and the operating-model side of running AI responsibly is the subject of the AI governance for enterprise operators guide.

8. Cost, capacity, tokens and rate limits

AI features have an ongoing running cost that traditional Business Central customisations do not, and understanding that cost model before you build is the difference between a feature that pays for itself and one that quietly bleeds budget. The unit of cost in Azure OpenAI is the token, which is roughly a fragment of a word, and you pay for tokens both going in (your prompt, including all that grounding context you injected) and coming out (the model's response). Every call has a price, and that price scales with how much context you send and how much text you ask the model to generate.

This has direct design consequences. A feature that stuffs an enormous amount of grounding context into every prompt, or that calls the model proactively on every record open whether the user needed it or not, will cost far more than a feature that retrieves only the relevant context and calls the model only when invoked. The grounding discipline that improves accuracy also controls cost: retrieve the right context, not all the context. Choosing the right model matters too, since more capable models cost more per token, and a lot of business tasks run perfectly well on a smaller, cheaper model. Matching model capability to task is a cost lever most teams discover too late.

There is also capacity and rate to think about. Azure OpenAI deployments have throughput limits, expressed in tokens and requests per minute, and if your feature is used at scale you can hit those limits and see calls throttled. Microsoft offers provisioned throughput for predictable high-volume workloads and pay-as-you-go for variable ones, and choosing between them is a real architectural decision for a feature that will be used heavily. Azure API Management in front of your calls lets you enforce your own limits, protecting both your budget and your capacity from a runaway loop or an unexpected spike. None of this is a reason to avoid building, but all of it is a reason to model the cost per interaction and the expected volume before you commit, so that the business case is built on the real economics rather than the demo.

The over-building caution: the most expensive AI feature is the one nobody needed. It is very easy, in the enthusiasm of a new capability, to wire AI into places where a simple rule, a saved filter or an existing report would have done the job for free and more reliably. Every AI call costs money and adds a component that can hallucinate, and a feature that saves a user four seconds twice a week does not justify either. Before you build, ask whether the task genuinely needs language understanding or reasoning, or whether it is deterministic work dressed up as an AI use case. Reserve the model, and its running cost, for the problems that actually require it.

9. Build versus buy: when to write custom AI and when to wait for Microsoft

This is the section I care about most, because it is where the money is won or lost, and where an honest advisor earns their keep by talking a client out of a build as often as into one. Microsoft is investing enormously in Copilot and AI inside Business Central and across Dynamics 365, and the packaged capabilities expand every release wave. That creates a genuine strategic tension: anything you build custom today, Microsoft might ship natively tomorrow, at which point your custom feature becomes maintenance debt that duplicates a platform capability you are already paying for. Respecting that tension is central to spending your AI budget well.

My framing is a simple set of questions. First, is this capability close to something Microsoft has already shipped or has clearly signalled on its roadmap? If yes, the default is to use or wait for the native feature, not to build. Second, is the value of having it now, ahead of Microsoft, large enough to justify building and then maintaining a custom feature that may be superseded? Sometimes it genuinely is, when the capability is core to how you operate and the advantage of having it early is real. Third, is this capability specific to your business in a way Microsoft will never build, because it depends on your data, your vocabulary, your process? That is the strongest case for custom, because it is the case Microsoft cannot serve from a general product. Fourth, do you have the engineering and the governance to run a custom AI feature responsibly over its whole life, not just to build it? An AI feature is not a one-time build, it is an ongoing operation with cost, monitoring and drift.

Run those questions and a clear pattern emerges. The strong custom-build candidates are the deeply domain-specific capabilities grounded on your proprietary data, the ones that embed AI reasoning into your particular workflow, the ones no general product will ever match. The weak candidates, the ones to buy or wait for, are the generic productivity assists, the drafting and summarising and matching tasks that Microsoft is already shipping or obviously will. The mistake I see most is building in the second category, burning engineering effort to replicate a feature that arrives natively two release waves later. The discipline is to build only where you have a durable reason Microsoft will not, and to let the platform carry everything else. That is not timidity, it is capital allocation, and it is the difference between an AI strategy that compounds and one that becomes a museum of superseded features.

10. A practical path to a first custom AI capability

If, having weighed all of that, you have a genuine custom AI use case, the sequence you follow matters as much as the technology you choose. The path I would advise for a first capability is deliberately narrow and disciplined, because the goal of the first build is to learn the whole loop safely, not to boil the ocean.

• Step 1: pick one narrow, high-value task. Choose a single, well-bounded scenario where AI clearly helps and the value is obvious, for example drafting a service report summary from work order data, or classifying incoming documents. One task, one screen, one clear win. Resist the urge to build a general assistant first.
• Step 2: prove the grounding. Before building any user interface, prove that you can retrieve the right Business Central data and get an accurate, grounded answer from Azure OpenAI. If the grounding is not solid, nothing built on top of it will be, so this is where the early effort belongs.
• Step 3: build it as a proper Copilot capability. Register the capability, use the platform's Copilot dialog pattern, keep a human in the loop with a generate-review-accept flow, and validate every response in code. Build it the responsible way from the start rather than as a throwaway that becomes production by accident.
• Step 4: wire in security and cost controls from day one. Authenticate with Entra ID, keep the AI within the user's permissions, ground with data minimisation, and put a limit and some logging in front of the calls. These are not phase-two items; they are part of the first build.
• Step 5: measure real usage and real cost. Once it is in front of users, watch how often it is used, whether the suggestions are accepted, and what each interaction actually costs. Let the evidence, not the enthusiasm, tell you whether to expand.
• Step 6: expand deliberately, and re-check build versus buy each time. Only extend to a second capability when the first has earned it, and each time ask again whether Microsoft has shipped something that now does the job for you. Deliberate expansion beats a sprawl of half-used AI features.

Notice that the first two steps involve almost no user interface and most of the risk. That is intentional. The value and the danger in custom AI both live in the grounding and the governance, not in the visible feature, so that is where a disciplined first build concentrates its attention. Get one narrow capability working end to end, safely and cheaply, and you will have learned more about building AI into Business Central than any number of demos can teach, and you will have a template you can apply to the next genuine use case with confidence.

Final thoughts

Building AI into Business Central has moved from a research topic to an everyday engineering choice, and the tooling, Azure OpenAI Service, the AL AI modules, the Copilot capability model, Copilot Studio and the emerging agents, has made the mechanics genuinely approachable. The plumbing is not the hard part. The hard parts are the ones that do not show up in a demo: grounding the model on your real data so it is accurate, governing what it can see and do so it is safe, controlling the cost so it pays for itself, and having the honesty to build only where Microsoft will not ship the capability for you. An operator who masters those four disciplines can add real, durable value on top of Business Central. One who chases the technology for its own sake ends up with expensive features that duplicate the platform and drift out of date.

My closing advice is the same one I give in every AI conversation. Start narrow, ground hard, govern from day one, watch the cost, and keep asking the build-versus-buy question honestly at every step. The teams that do this treat AI in Business Central as what it is, a powerful capability to be deployed with judgement on the problems that genuinely need it, rather than a badge to be worn on everything. That judgement, more than any API or any model, is what turns AI from a line item into an advantage.

Related reading: Copilot and AI in Business Central (hub), Practical prompt engineering for ERP consultants, Business Central and the Microsoft ecosystem, AI governance for enterprise operators, The Business Central roadmap for the next decade.