Business Central
Designing Business Central AI Extensions Around the Work
Where an AI-assisted extension can help, what belongs in ordinary business logic, and which controls to require before production.
The best place for an AI suggestion is often where the employee already makes the decision. A product-data warning beside the Item Card can be more useful than a separate chat window that requires copying records back and forth.
For a Business Central team, that raises a practical design question: what should the extension do, what information may it use, and which actions must stay behind normal business controls? Start with a bounded task, such as reviewing missing descriptive product fields or preparing an explanation of an exception.
Decide whether an extension is necessary
First inspect the installed application, existing extensions, available Microsoft features, and the organization’s current workflow. The need may already be covered by configuration, a report, or an existing integration. Building a custom extension creates maintenance responsibilities as well as new capability.
When customization is justified, Microsoft’s AL extension objects can add fields and actions to eligible pages and tables. For external integrations, Microsoft identifies the API stack as its preferred approach and supports built-in and custom APIs. Those are supported building blocks, not evidence that every desired field or operation is available in a particular tenant.
Have the implementation team confirm the Business Central version, deployment type, installed dependencies, license requirements, and relevant API surface. Avoid quoting a fixed integration effort before those facts are known.
Keep calculation and validation deterministic
Use ordinary application logic for required fields, allowed values, arithmetic, record identity, and permission checks. An AI model can help interpret unstructured material or draft an explanation, but it should not decide whether a user has authority to alter an item.
For a product-data assistant, show the suggested text beside the current value and supporting source. Let the reviewer accept, edit, or reject it. Preserve the distinction between “proposed” and “approved” in storage, not just in a paragraph on the screen.
Handle an empty response, unavailable model, or failed source lookup explicitly. The user should be able to complete the normal task without pretending the AI step succeeded.
A hypothetical Item Card assistant
Illustration only: Consider an assistant that helps a manufacturer prepare a distributor-facing product description. This is a design example, not an available Wheeler IS product or a report of customer results.
- The user opens an item and chooses to prepare a draft.
- The extension retrieves only approved, relevant fields and an authorized specification reference.
- AI proposes a description and lists any requested facts that are missing.
- The screen displays the sources and highlights differences from the current approved description.
- An authorized reviewer approves the text into a controlled field. Publishing to another system remains a separate, authorized workflow.
A missing storage instruction would stay missing and be flagged. The assistant would not infer it from a similar item. Price changes, posting transactions, and external publication are outside this hypothetical assistant’s scope.
Review both identity and permissions
Microsoft’s service-to-service authentication documentation describes application-identity access using OAuth and the need to grant the application permissions within Business Central. It explicitly calls for least privilege. An application identity is not automatically constrained to the records a particular employee can see.
Decide whether the workflow should operate as the user or as a narrowly scoped integration. Review company boundaries, object permissions, and the data returned by each operation. Microsoft also warns that permission-set extensions can add privileges. A new capability should trigger an effective-permissions review, not an assumption that old restrictions remain sufficient.
Keep credentials out of prompts, page text, and ordinary diagnostic logs. Review the AI provider’s data handling, retention, region, and contractual terms before sending business records. The necessary controls depend on the information and the organization.
Test in an environment with safe connections
Microsoft provides sandbox environments for development and testing. A sandbox still needs careful configuration: copied data may be sensitive, and connections to external services can have real effects. Confirm endpoints and test identities, and use synthetic or appropriately approved data.
Test ordinary permissions and denied permissions. Include a user in the wrong company, an obsolete source document, a record changed during review, a duplicate request, a timeout, and an unavailable downstream service. Verify that a failed AI call cannot silently overwrite an approved value.
Plan for upgrades to Business Central, dependencies, prompts, and models. The release package should identify what was tested and which changes require the tests to run again.
Questions to answer before production
- Which exact task becomes easier, and how will the team measure that?
- What data leaves Business Central, and who approved its destination?
- Which identity runs each operation, with which effective permissions?
- Who approves changes and owns the exception queue?
- How are sources, approvals, failures, and final record versions retained?
- How can the capability be disabled while normal work continues?
An extension is ready for a production decision when the business can answer these questions with evidence. A convincing demonstration is a useful beginning. Dependable operation requires the surrounding design, testing, and ownership.
Sources & further reading
- Microsoft extension objects
- Microsoft REST API overview
- Microsoft S2S authentication
- Microsoft permission sets
- Microsoft environment types
Primary references checked October 7, 2026. The practical recommendations and hypothetical examples are Wheeler IS editorial guidance; they are not customer results or vendor endorsements. Product capabilities and requirements can change.