How Can You Use AI Agents with Microsoft Dynamics 365 Business Central?

What is an AI agent in a Business Central context?

An AI agent carries out a defined sequence of work towards an assigned objective. Rather than responding only to a single question, it can interpret information and select steps within the actions available to it. For a business buyer, the important questions are which task it owns, what it can change and where a person must intervene.

Think in terms of delegated operational responsibility. A new sales administrator would need a role, access, instructions, supervision and a route for unfamiliar requests. An agent needs equally deliberate boundaries, with the additional recognition that model output can be incorrect or inconsistent. A natural-language instruction is part of that design, not a substitute for it.

Our Business Central consultancy provides a relevant starting point for assessing whether an agent fits your ERP processes. Begin with the work and its risk. The fact that a system can interpret a message does not establish that it should be permitted to commit the company to the action described in that message.

A useful design question is whether a supervisor could explain the agent’s work to a colleague who had never seen the demonstration. If the answer requires guessing which applications it can access or which actions it might take, the scope is not clear enough. Resolve that uncertainty before discussing a larger rollout or a more ambitious task.

How do agents differ from Copilot assistance and ordinary workflows?

Assistance usually begins when an employee asks for help or selects a feature. A workflow follows predefined events and conditions. An agent can interpret a task and pursue several steps within its permitted scope. These approaches are complementary, and a well-designed process may use all three without presenting them as interchangeable.

Take a purchase invoice as a practical example. Interpreting the document may benefit from AI. Checking whether the supplier is blocked is a rule. Deciding whether a disputed cost should be accepted requires an authorised person. The process becomes clearer when each responsibility is assigned explicitly instead of being placed inside one broad instruction to handle invoices.

Our Power Platform consulting services are relevant where a process crosses application boundaries or needs conventional orchestration. Ask a prospective supplier to explain why an agent is preferable to a simpler approach. The answer should identify the interpretation or decision problem the agent solves, together with evidence that the extra complexity is justified.

What can Sales Order Agent do, and where does a person remain involved?

Microsoft describes Sales Order Agent as handling customer email requests and helping prepare sales documents. The current overview explicitly requires designated users to review and approve outgoing messages. Evaluate the feature against that documented operating model rather than treating it as an unsupervised sales employee.

For your pilot, define the accepted customer population, product range and types of request. Decide who reviews a proposed reply when the usual account owner is absent. Consider whether a request concerns a new order, an amendment, a cancellation or a commercial dispute. They may need different handling even when they arrive in the same inbox.

Connect the test to fulfilment as well as document creation. Our Business Central supply chain services are relevant when assessing whether the resulting order contains usable availability and delivery information. Include cases where the correct outcome is to ask a human for clarification. A well-managed exception can protect the customer relationship more effectively than a quick but incorrect promise.

Manufacturers should also test whether the requested variant or specification is sufficiently clear before a sales document progresses. Our Business Central manufacturing consultancy is relevant to examining those process dependencies. An apparently minor difference in a customer description can matter to the team making or assembling the product, so involve that team in the acceptance examples.

What should we understand before using Payables Agent?

For payables, distinguish a prepared document from an authorised liability and a payment. The process should retain named responsibility for supplier verification, disputed amounts, approval and posting. An invoice arriving through a recognised technical route does not establish that the underlying request is genuine or contractually correct.

Microsoft’s Payables Agent documentation describes an invoice-drafting process with supervision and an unposted purchase invoice as an output. Its review step is distinct from a Business Central approval workflow, and the agent does not post the invoice. Build your operating procedure around those boundaries rather than assuming the agent performs the entire accounts payable function.

Our Business Central finance implementation services provide a relevant starting point for that assessment. Test the handover between the agent’s output and your existing finance controls. Include a supplier query, a mismatched delivery, an apparent duplicate and a document that should not become an invoice. Agree who resolves each issue and how finance can evidence the final decision.

Can we build our own Business Central agent?

Microsoft’s agent development documentation labels the design toolkit as preview and sandbox-only. It separately describes the Agent SDK for AL as available in production from version 28.1. That distinction matters: a prototype built to explore an idea should not automatically be treated as an approved production service.

Before commissioning custom work, ask whether an existing capability meets the requirement. Then document the gap precisely: which information must be interpreted, which actions are needed and which constraints prevent a standard solution from working. A broad ambition such as automate procurement is too vague to estimate or test reliably.

Our AI consultancy services offer a relevant route for evaluating the use case before committing to development. Require separate proof-of-concept and production acceptance decisions. The latter should cover security, support, performance, exception handling and commercial ownership. A convincing demonstration can justify further investigation while still leaving substantial engineering and operational questions unresolved.

How should we define the agent’s job and its boundaries?

Write a role description that a supervisor can use. State its purpose, permitted inputs, expected outputs, prohibited actions, approval points and escalation conditions. Include the company or business area it serves and the data it is allowed to use. Avoid vague authority such as use your judgement whenever the process has a material financial consequence.

Use examples to make the boundaries concrete. An agent might prepare a draft using an existing price agreement while escalating a request for a special discount. It might extract supplier information without approving a change to bank details. These examples are design choices to agree with the business, not a promise that a particular built-in agent supports every variation.

Define completion as a business state rather than an agent saying that it has finished. Has the order been reviewed? Is the document in the correct queue? Can another employee trace the source? Clear completion criteria make it possible to test the process and prevent a successful technical task from being mistaken for a completed business transaction.

What access and identity arrangements does the agent need?

Create an access design before activating a live process. Identify the required records, actions, companies and mailboxes. Record who approves the initial access and who reviews it when responsibilities change. A convenient administrative account can hide missing design decisions and expose far more information than the task needs.

Test permissions from the agent’s actual context. A process can appear to work during a demonstration because a developer has broad access, then fail or behave differently when deployed with a restricted role. Conversely, granting broad permissions to remove a failure may defeat an important business boundary. Investigate the required action rather than expanding access reflexively.

Our managed security services are relevant to discussions about identities, privileged access and monitoring across connected systems. Retain a record of the approved scope and include agent access in routine reviews. Removing an employee’s access is not enough if an agent, integration or shared mailbox continues to hold authority that depended on that person’s role.

How do we choose and prepare the data the agent uses?

Examine the records needed for the chosen task. Identify ambiguous customer contacts, obsolete item references, inconsistent supplier names or missing ownership. Prioritise defects that can change the business outcome. Improving a targeted set of records is usually more actionable than announcing a general data-cleansing programme without a defined endpoint.

Ask experienced staff to explain how they resolve uncertain cases. If they rely on memory, an undocumented agreement or a colleague’s private spreadsheet, decide how that knowledge should be represented. Some information belongs in structured master data. Other judgement should remain an exception for a person. Avoid hiding important policy inside a long prompt that nobody owns.

Prepare a reference set of transactions with agreed expected outcomes and retain it for regression testing. Use realistic formats and awkward cases, with suitable protection for sensitive information. Keep a record of changes to the test data. Without a stable benchmark, each adjustment can look like an improvement simply because the examples have changed alongside it.

What should happen when the agent is uncertain or a task fails?

Define an exception queue with an owner, priority and maximum acceptable age. A task that pauses safely is still a business item waiting for action. Decide how staff distinguish missing information, an unsupported request, a permissions problem and a service interruption. Those causes need different responses and should not all become generic AI errors.

Specify whether a retry is safe. If an earlier step created a document or sent a message, rerunning the entire task might duplicate work or confuse the recipient. A supervisor should be able to see what already happened before deciding how to continue. Keep the original request linked to the resulting records wherever the design allows.

Our system integration services are relevant when investigating failures between applications. Agree how work resumes after an interruption, how duplicate events are detected and who reconciles outstanding items. Include a manual fallback that employees can actually operate. An exception procedure that depends on the unavailable developer is an unresolved operational dependency, not a completed support arrangement.

How should we test an agent before it handles live work?

Start with clear acceptance criteria for accuracy, safety and operational usefulness. A correct-looking response is only one measure. Check that the right records change, the required review happens and the task leaves an understandable audit trail. Include a criterion for correct refusal or escalation when the request is outside scope.

Build the test pack with the staff who deal with difficult cases. Include unknown senders, conflicting references, amended requests, duplicate documents and incomplete information. Test plausible malicious or misleading instructions in incoming material without exposing production data or allowing real commitments. Confirm that the process retains its intended authority boundaries.

Run the first live stage with limited volume and designated supervision. Review every outcome at first, record corrections consistently and compare them with the baseline. Do not relax oversight solely because the first few tasks succeed. Choose a meaningful observation period that includes ordinary exceptions, staff absences and changes in workload before making a decision about wider use.

How do we budget for agent consumption and supervision?

Treat the agent as an operating process with several cost components. Besides any subscription or consumption charges, include setup, testing, supervision, support and change management. The most persuasive business case accounts for the whole workflow and explains how released time will be used. Counting gross minutes saved can overstate the benefit.

Microsoft’s built-in agents can use Copilot Credits, so confirm current billing arrangements for the precise capability and environment. Ask how task complexity, retries, mailbox volume and extended conversations affect the estimate. Do not assume that an assistive feature’s licensing terms also cover every agent or custom solution.

Set an accountable budget owner and a review cadence. Agree what happens if consumption exceeds the expected range or useful throughput falls. A cheap task that needs substantial correction may be more expensive than the existing process. Pilot figures should distinguish successful work, rejected work, retries and supervision effort, making the trade-off visible rather than reporting only the total number of agent tasks.

What should we monitor after an agent goes live?

Monitor completed business outcomes, not just whether the service is running. Useful measures include the age of queued requests, the correction rate, time to resolution, manual interventions and tasks processed outside the expected pattern. Compare similar types of work, so a change in transaction mix does not disguise a quality problem.

Keep technical monitoring connected to operational ownership. A successful execution signal does not prove that a customer received the correct promise or that finance accepted the document. Agree who investigates each measure and which threshold triggers action. Add a short review of recent exceptions to the normal process meeting rather than creating a report nobody uses.

Our Power BI reporting services can be relevant when consistent reporting across process stages is required. Preserve enough context to explain why an outcome changed. When instructions, extensions or business rules change, mark the date and repeat relevant tests. This makes it easier to separate real process improvement from a change in how work is counted.

Who owns the agent when the original project team moves on?

The business needs an accountable process owner even if a partner provides technical support. That owner approves scope, accepts results and decides whether the process still meets business needs. A technical supplier can maintain components without possessing the authority to decide how your company should treat customers, suppliers or financial exceptions.

Document support responsibilities across the ERP partner, Microsoft services, any extension publisher and internal staff. Clarify the information required to investigate a failed task and who coordinates a case involving several systems. Keep access arrangements, configuration records and escalation contacts available to authorised staff, rather than leaving them in one consultant’s notes.

Our managed IT support services provide a relevant route for discussing the wider operational dependencies. Plan for holidays, staff turnover and the end of a supplier relationship. The agent should remain understandable and controllable after the people who built the demonstration have left. Ownership is demonstrated by an effective operating routine, not merely by a name in the project plan.

How can we decide whether to expand, revise or stop the pilot?

Compare the results with criteria agreed before launch. Assess quality, cycle time, workload, operating cost and the severity of exceptions. Consider whether the process improves the experience of the next team in the chain. Transferring effort from order entry to fulfilment may create the appearance of automation while leaving the business worse off.

Expand only into a defined adjacent scope. A successful pilot for a stable product group does not establish readiness for every customer, company or transaction type. Identify what changes in the new scope, update the test pack and confirm supervision capacity. Keep the previous configuration and a record of the evidence supporting the decision.

Stopping or revising a pilot is a useful outcome when the evidence shows that a simpler workflow, better data or a revised operating process would help more. Capture what was learned and retain the reusable test cases. The goal is dependable business performance. Treat the agent as one possible tool for achieving it, with a clear reason for every increase in responsibility.