# How to add AI agents to Microsoft Dynamics NAV > Source: https://netray.co/integrations/dynamics-nav-ai-agents > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## Short answer Build a thin tool layer over NAV's published web services (OData, SOAP codeunits) and a read-only SQL replica, then let an agent plan multi-step work such as PO expediting or planning exception triage. Every write goes through a NAV codeunit and a human approval step. The whole stack can run on-prem next to the NAV service tier. ## System Microsoft Dynamics NAV ## Capability ai-agents ## Intro Many manufacturers still run Dynamics NAV 2009, 2013, 2016 or 2018 on a Windows Server and SQL Server they own. The system works, the customizations in C/AL are decades deep, and nobody wants a forced move to Business Central just to get AI. The good news is that an agent does not need to live inside NAV. It needs a safe way to read data and a narrow, audited way to propose changes. An AI agent differs from a chatbot because it carries a goal across several steps: find the late purchase lines, check the vendor's history, draft a reschedule request, wait for a buyer to approve, then post the change. NAV gives you the pieces for this through page and codeunit web services, the Job Queue, and SQL access to the ledger tables. The honest caveat is that older NAV versions have uneven API support. Pre-2013 installs only have SOAP and limited page services, so the agent leans harder on SQL reads and a small number of purpose-built codeunits for writes. ## Use Cases ### Late purchase line expediting **Description:** The agent scans open Purchase Line records past their Expected Receipt Date, checks the vendor's recent delivery record from Vendor Ledger and Item Ledger entries, and drafts reminder emails for the buyer to approve. ### Planning worksheet triage **Description:** After the planning run, the agent reads Action Messages on the Planning Worksheet (Requisition Line) and groups them: safe to carry out, needs a buyer, or caused by bad lead time data. ### Production order shortage chasing **Description:** For released production orders, the agent compares Prod. Order Component remaining quantities with Item inventory and open supply, and lists which orders will stall first. ### Draft nonconformance and rework orders **Description:** From a quality hold note, the agent proposes an NCR record in your custom table or a rework production order, with the item, lot and operation filled in for review. ### Month-end data hygiene **Description:** An agent checks for items without routings, vendors without payment terms, and BOMs with certified status mismatches, then queues fix proposals for the data steward. ### Customer order status answers **Description:** Sales staff ask where an order is. The agent follows Sales Header to Shipment, Production Order and Purchase Line links and returns one plain answer with the evidence rows. ## System Surface Web services: publish pages and codeunits from the Web Services page (the exact path varies by version); NAV 2013 and later expose them as SOAP and OData, and later releases add an OData V4 option. Codeunits as the write path: write a small custom codeunit per action (for example, change expected receipt date) so business rules, field validation and permissions run in C/AL or AL rather than being bypassed. SQL Server: each company has its own table set named like CompanyName$Item Ledger Entry, plus SIFT views for totals. Use a read-only replica or a restored copy for agent queries, never the production login. Job Queue and NAS (NAV Application Server): schedule batch work and polling without a client session, on versions that support it. Event subscribers (NAV 2016 and later): publish a message to a queue when a Purchase Line or Production Order changes, so the agent reacts instead of polling. ## How It Works ### Pick two or three narrow jobs **Detail:** Start with a read-heavy job such as late PO review. Define the inputs, the decision, and what a human must approve. Avoid broad goals like run purchasing. ### Expose read tools **Detail:** Publish pages like Purchase Lines, Item Card and Prod. Order Components as web services, or build parameterized SQL views on a replica. Each tool returns a small, typed result. ### Expose write tools as proposals **Detail:** Write tools do not change data. They create a proposal row in a staging table. A separate codeunit applies approved proposals under a dedicated NAV service user. ### Run the agent loop on a private model **Detail:** An open-weight model with tool calling, served by vLLM or Ollama, plans steps and calls the tools. Cap the number of steps and log each call with its arguments. ### Add the approval screen **Detail:** Show each proposal with the evidence rows and a one-click approve or reject, in a web page, a Teams card or a custom NAV page. Approval triggers the codeunit. ### Evaluate before widening **Detail:** Replay a month of history, compare agent proposals to what the buyer actually did, and only then add a second job. ## Example Flows ### Expedite late purchase lines **Trigger:** Nightly Job Queue entry fires at 05:00. **Steps:** - Agent lists open Purchase Lines with Expected Receipt Date earlier than today and a production demand within 10 days. - For each vendor it reads the last 12 receipts to estimate typical lateness. - It drafts a short reminder per vendor and a proposed new date for lines with no response. - The buyer sees a queue of proposals and approves, edits or rejects each one. **Result:** Buyers start the day with a prioritized, evidence-backed list instead of scanning a purchase line page. ### Shortage alert to firm planned order **Trigger:** A released production order shows a component shortage after a planning run. **Steps:** - Agent reads the Prod. Order Component and finds the short item. - It checks open purchase supply, transfers and alternate items on the BOM. - It proposes either a date pull-in on an existing PO or a new purchase requisition line. - A planner approves, and the codeunit writes to the Requisition Worksheet for the normal carry-out. **Result:** Shortages are resolved through the standard NAV carry-out path, so planning rules and approvals still apply. ## On Prem Run everything inside your network. The agent runtime, the model server on your GPUs, the vector index for any documents, and a read-only SQL replica sit in the same segment as the NAV service tier. The agent calls the NAV web services with a Windows-authenticated service account scoped by NAV permission sets, so no data leaves the building. For air-gapped sites, models are loaded from an internal artifact store and updated by sneakernet or a controlled mirror. Because old NAV hosts may run unsupported operating systems, keep the agent on a separate modern host and connect only over the published service ports. ## Security - Use a dedicated NAV user with a minimal permission set for tools, never a super user or the DBA login. - Read from a replica or restored copy so heavy queries cannot lock production ledger tables. - All writes are proposals applied by a codeunit after named human approval, and the approver is recorded. - Log every tool call, argument and result with a request ID so you can reconstruct why the agent suggested something. - Mask or exclude sensitive fields such as bank account numbers from tool outputs. ## Options ### Build in-house with a NAV developer and a Python agent framework **Fit:** You have a NAV developer who knows C/AL and a team comfortable running a model server. **Effort:** Roughly 6 to 12 weeks for the first narrow job, including evaluation. ### Use a generic automation platform (Power Automate, RPA) with LLM steps **Fit:** Simple linear flows on a cloud-friendly install; weaker for multi-step reasoning and on-prem models. **Effort:** A few weeks per flow, but ongoing maintenance of brittle steps. ### Work with a partner such as Netray for the agent layer **Fit:** You want a private, on-prem agent with approvals and prefer your NAV partner to keep owning the codeunits. **Effort:** Typically a scoped pilot over several weeks, then extended job by job. ## Pitfalls - Letting the agent write directly to tables over SQL skips NAV validation and corrupts ledgers; always go through codeunits. - Heavy customization means standard table assumptions fail. Inventory your extra fields and custom tables before designing tools. - Per-company table names break copy-pasted SQL. Parameterize the company prefix. - Giving the agent too many tools makes it wander. Start with under ten. - Skipping a replay evaluation means the first bad suggestion costs the project its credibility. ## Faq ### Can AI agents work on NAV 2009 or 2013? **Answer:** Yes, but the path differs. Older versions have limited web service support, so agents lean on read-only SQL and a few purpose-built codeunits exposed as SOAP. Writes remain narrow and approved. If the install is very old, consider a staged upgrade in parallel. ### Does the agent need to run inside NAV? **Answer:** No. It runs outside as a separate service and talks to NAV through web services and a replica. This keeps the legacy host untouched and lets you upgrade the model without touching C/AL. ### How do we stop the agent from posting bad data? **Answer:** Agents only create proposals. A codeunit applies them after a named human approves, and NAV's own validation still runs. You can also limit the service user's permission set to the specific tables involved. ### Which model should we use? **Answer:** For on-prem, an open-weight model with reliable tool calling in the Llama, Qwen or Mistral class is a common start. Test on your own historical cases; model size matters less than clean tool design and evaluation. ### Is this worth it if we plan to move to Business Central? **Answer:** Often yes. The tool layer and approval workflow carry over, since Business Central offers similar APIs. Only the connector changes. Just keep the agent logic separate from NAV-specific code. ## Search terms dynamics nav ai agents, ai agents for dynamics nav, add ai to dynamics nav, dynamics nav automation ai, dynamics nav llm integration, dynamics nav purchasing agent, dynamics nav on-prem ai, navision ai agent --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json