# AI for Business Central manufacturing operations, beyond Copilot > Source: https://netray.co/erp-ai/business-central-manufacturing-ai > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer Business Central's Copilot features are real, but they lean toward sales text and marketing content, not shop-floor questions. An AI layer grounded on Business Central's manufacturing data through its OData and REST APIs can answer production order, routing, and capacity questions directly, with any write-back handled through an approved AL extension rather than a blind automation. ## Kind platform ## Erp Family microsoft ## Erp Products - Dynamics 365 Business Central - Business Central Manufacturing - Business Central on-premises ## Industries - Manufacturing - Electronics ## Region United States ## Persona Operations Manager ## Eyebrow Business Central Manufacturing + AI ## Intro Business Central is a capable mid-market ERP, and its Manufacturing module (production BOMs, routings, work and machine centers, capacity planning, version management) covers real ground for a discrete or light process manufacturer. Microsoft has also been adding Copilot features into Business Central, but an operations manager who actually opens them finds they lean toward sales line suggestions and marketing text generation, not the question a shop supervisor has at 6am about why production order 108452 is behind schedule. That gap is not a criticism of Business Central; it is a reasonable product decision by Microsoft to build the Copilot features with the broadest applicability first. But it leaves manufacturing-specific question answering, capacity exception detection, and BOM change impact analysis as work an operations team still does manually, usually by exporting data to Excel or waiting on whoever built the last Power BI report. Business Central's manufacturing data model is genuinely well-suited to an AI layer once it is properly grounded: Production Order, Prod. Order Routing Line, Capacity Ledger Entry, and Production BOM are clean, well-related tables, reachable through the APIs v2.0 (OData v4 and REST) that Microsoft has invested heavily in. The engineering work is building the semantic layer that accounts for the custom AL fields most manufacturers add, and building any write-back path as a proper AL extension with an explicit approval step, rather than a workaround that bypasses Business Central's own business logic. For manufacturers running Business Central on-premises (still a supported deployment option) as well as those on the SaaS service, the same architecture applies: read Business Central's manufacturing data through its standard APIs, ground a model on it, and keep the model and any agent logic on infrastructure appropriate to the company's data sensitivity, whether that is fully on-prem for an electronics manufacturer with defense-adjacent customers, or a dedicated cloud tenant for everyone else. ## Pain Points ### Copilot in Business Central covers sales and text generation, not the shop floor **Detail:** Native Copilot features are built around sales line suggestions and marketing content; a supervisor asking about production order status or capacity has no equivalent self-service tool. ### Production order status means logging into Business Central or waiting on a report **Detail:** Shop-floor staff without a full Business Central license, or without report-building skill, cannot get a straight status answer without asking someone who has both. ### Component shortages are discovered late **Detail:** Nothing proactively flags a production order at risk of a component shortage before it is released to the floor, without a custom Power BI dashboard someone has to build and maintain. ### Standard cost variance is hard to explain quickly **Detail:** Understanding why a standard cost variance appeared on a production order means manually comparing the Standard Cost Worksheet against actual item ledger activity. ### Small manufacturing IT teams cannot build custom reporting for every question **Detail:** Mid-market Business Central manufacturers rarely have a dedicated BI resource, so most operational questions outside the standard role centers go unanswered. ## Use Cases ### Plain-English production order status **Description:** A supervisor or planner asks what stage a production order is at, or which orders are behind schedule this week, answered from live Production Order and routing data. **Erp Objects:** Production Order, Prod. Order Line, Prod. Order Routing Line **Outcome:** Cuts the time to get a status answer from a Business Central login or a report request down to a direct question. ### Routing and capacity exception flagging **Description:** An agent compares actual operation progress against routing standard times and work or machine center capacity, flagging orders trending late before the ship date is at risk. **Erp Objects:** Prod. Order Routing Line, Capacity Ledger Entry, Work Center/Machine Center **Outcome:** Surfaces at-risk production orders earlier than a manual end-of-week review would catch them. ### BOM and version change impact summary **Description:** When a Production BOM version changes, an agent summarizes what changed in plain language and flags any open production orders still tied to the prior version. **Erp Objects:** Production BOM, Version Management, Production Order **Outcome:** Reduces the risk of a production order running against a stale BOM version by making the change visible immediately. ### Component shortage lookup against open orders **Description:** Planners ask whether enough of a component is available for this week's production orders, checked against reservations and on-hand inventory. **Erp Objects:** Item, Reservation Entry, Prod. Order Component **Outcome:** Faster shortage identification ahead of a release to the floor, instead of discovering the gap after the order is released. ### Standard cost variance explanation **Description:** A cost accountant asks why a production order showed a standard cost variance and gets a plain-language breakdown grounded in item ledger and standard cost worksheet data. **Erp Objects:** Standard Cost Worksheet, Item Ledger Entry, Value Entry **Outcome:** Turns a manual cost investigation into a grounded explanation with every figure traced to source entries. ### Text-to-query for planning worksheet questions **Description:** Planners ask questions in plain English that get translated into a query against the Planning or Requisition Worksheet, executed read-only, with the underlying filter shown. **Erp Objects:** Planning Worksheet, Requisition Worksheet **Outcome:** Removes the report-building bottleneck for routine planning questions that fall outside the standard worksheets. ### Approval-gated production order updates **Description:** An agent can draft a proposed operation completion or a routing note from floor input, but the actual update to Business Central goes through an AL extension with a supervisor's explicit approval. **Erp Objects:** Production Order status field, custom AL event subscribers **Outcome:** Speeds up floor data entry without removing supervisor control over what actually posts in Business Central. ## Architecture **Overview:** A read-mostly layer on Business Central's APIs v2.0 (OData v4 and REST) grounds question-answering and exception detection in live manufacturing data, with any write-back handled through a dedicated AL extension and Business Events rather than a bypass of Business Central's own logic. **Layers:** #### Business Central connectors **Detail:** OData v4 and REST APIs v2.0 for reads against Production Order, Routing, and Item data; an AL extension using Business Events for anything that needs to write, always behind an approval step. #### Semantic layer **Detail:** A mapping between Business Central's standard manufacturing fields and the custom AL fields most manufacturers add, since production processes vary enough that the standard schema rarely tells the whole story. #### Model serving **Detail:** Open-weight models served on-prem or in a dedicated cloud tenant, sized for a manufacturing team's query volume rather than a large enterprise deployment. #### Retrieval and agents **Detail:** Text-to-query for structured production and planning questions, exception-detection agents that poll routing versus actual progress, and document RAG for travelers and supplier certificates. #### Governance and audit **Detail:** Every agent action logged with the API call it made; write actions through the AL extension require a named approver and are logged accordingly. ## Deployment Options ### Air-gapped on-prem **Fit:** Electronics manufacturers running Business Central on-premises with defense-adjacent customers whose compliance requirements push toward keeping AI infrastructure off the public internet. **Detail:** Model and agent logic run on customer-owned hardware, connecting outbound to a self-hosted Business Central instance over a controlled, logged connection. ### Private or dedicated cloud **Fit:** Most Business Central SaaS manufacturers, since Business Central itself is already cloud-hosted and the AI layer can reasonably live in a dedicated tenant alongside it. **Detail:** Model serving in a single-tenant environment, connecting to Business Central over Azure AD app registration and OAuth, with no data routed through a shared public AI service. ### Hybrid **Fit:** Companies piloting a single use case, such as production order status, before deciding on the long-term hosting model. **Detail:** Small-footprint pilot on a modest instance, same API connector pattern, migrated to the target hosting model once the use case proves out. ## Compliance ### Read-only access to standard cost and item ledger data for variance explanation; any correction still goes through Business Central's own posting and approval workflow. **Framework:** SOX / financial controls ### For electronics manufacturers with defense-adjacent customers, the AI layer and model can be kept fully on-prem or in a controlled tenant, with access scoped to authorized staff. **Framework:** ITAR / EAR (where applicable) ### Agent access mirrors Business Central's existing permission sets; a shop-floor query tool does not surface finance or HR data the underlying permission set would not allow. **Framework:** Data access scoping ### Any AI-proposed update to a production order goes through the dedicated AL extension's approval logic and Business Central's own audit trail, with the AI's role limited to drafting the proposal. **Framework:** Change management ## Integration Notes Use OData v4 or the REST APIs v2.0 for read-heavy question-answering; both are well-documented and stable across recent Business Central versions. Authenticate via an Azure AD app registration with OAuth 2.0 client credentials, kept separate from individual user logins, so agent activity is separately auditable. Map custom AL fields early: most manufacturers extend the standard Production Order and Item records with process-specific fields, and those need to be in the semantic layer or the agent will miss real context. Build any write-back as a dedicated AL extension using Business Events, rather than writing to tables directly; this keeps Business Central's own validation and posting logic intact. Confirm which API version and which manufacturing entities are exposed if the customer runs Business Central on-premises rather than the SaaS service, since on-prem configurations can lag the latest API surface. For exception-detection agents comparing routing pace to actual progress, run on a schedule against a cached snapshot rather than polling live on every check, to respect API throttling limits. Keep write-back scoped narrowly at first, such as operation completion notes only, and expand only after the read-only use cases have built trust with the floor team. ## Product Fit ### ERPray **Why:** ERPray's connector model fits Business Central's OData and REST APIs directly, giving operations managers grounded, cited answers to production and capacity questions without a custom build. ### Custom build **Why:** Exception-detection agents tuned to a specific routing structure, and the approval-gated AL extension for write-back, are typically a custom build layered on the ERPray connector. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - Mapping of custom AL fields on Production Order, Routing, and Item records - Confirmed API connectivity and Azure AD app registration setup - Prioritized use case (status lookup vs. exception detection vs. cost variance) - Success criteria agreed with operations and IT ### Pilot **Duration:** 6-8 weeks **Deliverables:** - Working text-to-query layer for the pilot use case - 5-10 real shop-floor questions answered end to end with the underlying API call visible - Exception-detection logic validated against a known late production order from history - Pilot review with operations manager and Business Central administrator ### Production **Duration:** 6-8 weeks **Deliverables:** - Role-based access aligned to existing Business Central permission sets - AL extension built and tested for any approved write-back - Audit logging of all agent queries and approved write actions - Shop-floor rollout with a simple interface rather than the full Business Central client ### Scale **Duration:** ongoing **Deliverables:** - Additional use cases, such as shortage flags and cost variance explanation, added incrementally - Approval-gated write-back expanded where trust has been established - Quarterly review of query patterns and false-positive rate on exception flags ## Buyer Questions - How do you authenticate to Business Central, and is agent activity separately auditable from human user activity? - Will this respect our existing Business Central permission sets, or does it need a broad service account with wide access? - What exactly writes back to Business Central, and is it built as a proper AL extension or a workaround that bypasses standard logic? - How do you account for the custom AL fields we've added to Production Order and Item records? - Where does the model run, and can we keep this off a shared public AI API if our customers require it? - Can you show a real example of the query your system generated for a production order status question? - Does this work the same way if we run Business Central on-premises instead of the SaaS service? - What is the fallback if Business Central's API is briefly unavailable during an update? ## Faq ### Can AI answer production order and routing questions directly from Business Central? **Answer:** Yes. Using the OData v4 or REST APIs v2.0, an AI layer can query live Production Order, Routing, and Item data and answer questions in plain language, with the underlying API call shown for verification. This is read-only by default and does not require reconfiguring the Manufacturing module. ### Is Business Central's built-in Copilot enough for manufacturing questions? **Answer:** Native Copilot features in Business Central lean toward sales line suggestions and text generation rather than shop-floor question answering or capacity exception detection. A grounded agent layer built on the manufacturing APIs fills that specific gap; the two are complementary. ### Will an AI agent write to my production orders automatically? **Answer:** Not by default. The standard design is read-only for status and exception use cases, with any proposed write, such as completing an operation, built as a dedicated AL extension requiring explicit supervisor approval before it posts through Business Central's own logic. ### Do we need to reconfigure our Manufacturing module to use this? **Answer:** No. The AI layer reads existing Production Order, Routing, and Item data through standard APIs. It does not require changing manufacturing settings, and it respects your existing Business Central permission sets. ### How does this handle custom fields we've added to production orders? **Answer:** Custom AL fields need to be mapped into the semantic layer during discovery, since most manufacturers extend the standard Production Order and Item records with process-specific fields. Skipping this step is the most common reason a pilot underperforms. ### Does this work for Business Central on-premises, not just the cloud service? **Answer:** Yes, with a caveat: the API surface and enabled entities can lag between on-premises and SaaS releases, so discovery confirms which manufacturing entities are actually exposed on the specific on-prem version before scoping the connector. ### What Business Central APIs does this rely on? **Answer:** Primarily the OData v4 and REST APIs v2.0 for reads, with any write built as a dedicated AL extension using Business Events. Authentication is typically an Azure AD app registration with OAuth 2.0 client credentials, kept separate from individual user logins. ## Search terms Business Central manufacturing AI, Business Central AI integration, AI for Business Central manufacturing, on-prem AI for Business Central, Business Central copilot manufacturing, Business Central production order AI, Business Central generative AI, BC manufacturing AI agent, Business Central capacity planning AI, Business Central BOM AI, Business Central natural language query, Dynamics 365 Business Central AI manufacturing --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json