# Adding a Private AI Layer to Dynamics NAV On-Prem

> Source: https://netray.co/erp-help/private-ai-layer-dynamics-nav-on-prem-architecture
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

Dynamics NAV can feed a private AI assistant through two safe doors: a read-only SQL Server copy for analytical questions and published web services (OData and SOAP) for anything that must respect NAV logic and permissions. Put an open-weight model and a retrieval index beside them on your own hardware and keep writes behind human approval and codeunit-based services.

## Kind

advanced

## System

dynamics

## Erp

Microsoft Dynamics NAV

## Module

Data access / Web services / SQL Server / Permissions

## Query

how to add AI to Dynamics NAV on-prem

## Alternate Queries

- Dynamics NAV AI integration without cloud
- NAV 2018 local LLM over item ledger entries
- Dynamics NAV OData chatbot on premises
- NAV private AI architecture

## Applies To

Dynamics NAV 2013 to NAV 2018 (including 2013 R2, 2015, 2016, 2017) on SQL Server; NAV 2009 R2 with the classic client needs a different approach

## Steps

### How to stand up a private AI layer on NAV

**Items:**

- List the questions to answer first: item availability, open sales and purchase lines, customer ledger balances, production orders, serial and lot traceability.
- Make a read-only SQL copy using AlwaysOn, log shipping or a nightly restore, and create a separate SQL login with SELECT on curated views only.
- Generate a table map: NAV table names include the company name, for example [CRONUS$Item Ledger Entry], so build one view set per company or a union view with a company column.
- Publish the pages and query objects you want through the Web Services list and test them over OData with a service account that holds a minimal permission set.
- Index attachments, item descriptions, comments and external documents referenced from NAV records into a local retrieval store.
- Expose read actions through a tool server with strict parameter validation and a row limit, and log every call.
- Serve the model with vLLM or Ollama on local GPUs and run a ten-user read-only pilot before enabling any drafts.

## Sections

### Real data access paths in NAV

**Body:**

NAV runs on SQL Server with one set of tables per company, named with the company prefix, such as [CRONUS$Item], [CRONUS$Sales Header], [CRONUS$Sales Line], [CRONUS$Cust_ Ledger Entry], [CRONUS$G_L Entry] and [CRONUS$Item Ledger Entry]. Special characters in object names become underscores in SQL. Option fields are stored as integers, and many tables carry a timestamp column that is useful for incremental change detection. Calculated FlowFields do not exist in SQL, so values like inventory or balance have to be recomputed from ledger entries in your view.

For supported access, NAV 2013 and later let you publish pages, queries and codeunits as web services. Pages and queries are available over OData, and codeunits and pages over SOAP; later versions add OData v4. Published pages enforce permissions of the calling user and run NAV business logic on insert or modify. Use SQL on the replica for broad analytics and web services when row-level security or calculation rules matter.

**Code:**

-- Read-only: inventory by item from item ledger entries (replace company prefix)
SELECT ile.[Item No_],
       SUM(ile.[Remaining Quantity]) AS OnHand
FROM   [CRONUS$Item Ledger Entry] ile
WHERE  ile.[Open] = 1
GROUP BY ile.[Item No_]
HAVING SUM(ile.[Remaining Quantity]) <> 0;

-- OData read through a published page (service name is whatever you registered)
GET https://nav-srv:7048/NAV/OData/Company('CRONUS')/ItemList?$filter=Inventory gt 0&$top=50

### Reference architecture and air-gapped option

**Body:**

The layout is the same as for other on-prem systems. A read-only replica supplies facts; change tracking on timestamp columns or SQL Server change data capture feeds incremental updates to the retrieval index; a tool server exposes approved read actions; an open-weight model served on local GPUs does the language work; and every question, tool call and answer lands in an audit log you control.

Because the NAV Service Tier can be the single choke point, many teams route anything that needs business logic through it and use SQL only for aggregates. In an air-gapped plant the whole stack, including model files and container images, is brought in by controlled media transfer and kept on an isolated segment. The trade-off is that you own model updates, evaluation and patching.

### Permissions and write-back

**Body:**

NAV authorisation is built from permission sets and permissions assigned to users and, in later versions, user groups, stored in tables such as Access Control and Permission, with company-specific restrictions and optional security filters on tables. The assistant should resolve the signed-in user to a NAV user, then either call web services as that user through delegation or enforce an equivalent filter in tool code. Do not assume SQL views reproduce NAV security; test with a low-privilege user and compare answers.

For write-back, let the assistant produce a draft and require a person to approve it, then post it through a codeunit or page published as a web service so NAV validation, number series and posting routines run. Direct SQL writes to NAV tables are not supported and will corrupt data integrity, so keep the assistant's SQL login read-only.

### Sizing, rollout and honest limits

**Body:**

A 50 to 200 user NAV estate often needs one inference GPU for an 8B to 32B class model, and a small server for the index and tool server; a document set of tens to hundreds of thousands of pages typically indexes into a few gigabytes to low tens of gigabytes. Phase one is read-only answers, phase two is drafts for human review, phase three is a short list of approved actions.

Limits to state plainly. NAV 2018 is the last NAV release and the product line continues as Business Central, so integrations should be built on views and a tool layer you can repoint. Heavily customised C/AL logic that is not exposed as a service cannot be called by the assistant. If your only goal is dashboards, Power BI on the replica is simpler than a language model.

## Pitfalls

- Forgetting that tables are per company. A query without the right prefix silently answers for the wrong company or returns nothing.
- Reading SQL for values that are FlowFields in NAV. Recompute them from ledger entries and reconcile against a NAV page before trusting them.
- Letting the service account hold SUPER permissions. A tool server should authenticate with a narrow permission set.
- Assuming OData v4 is available on old builds. Check your version before designing the connector.
- Skipping a timestamp or change-tracking strategy and re-indexing everything nightly, which stalls the replica.

## Ai Angle

A grounded assistant on NAV answers from item ledger entries, open document lines and attachments, shows the SQL or OData call behind each number, and respects the asking user's NAV permissions. Netray builds this as a custom private layer per estate, with open-weight models on your GPUs and no data leaving your network.

## Faq

### Does NAV need to be upgraded before adding AI?

**Answer:** No. A read-only layer works on NAV 2013 to 2018 as long as you can create a replica and publish web services. An upgrade to Business Central is a separate decision, and a well-designed tool layer can be repointed to it later.

### Are NAV OData web services secure enough for an assistant?

**Answer:** They are as secure as your configuration: use Windows or Kerberos authentication, a least-privilege service identity or delegation, and TLS. Published pages apply the caller's NAV permissions, which is the main advantage over raw SQL.

### Can the assistant post sales orders?

**Answer:** Only through a supported service and only after a person approves the draft. Phase the capability in after read-only answers have been measured for accuracy.

### Do we need a vector database?

**Answer:** Only if you want to search documents and long text. For structured questions the tool server and SQL views carry the load. Start with a small local index and grow it when users ask document-heavy questions.

## Search terms

Dynamics NAV AI integration, NAV on-prem local LLM, NAV OData web services AI, NAV 2018 AI assistant, NAV permission sets, NAV SQL Server item ledger entry, private AI Dynamics NAV, air-gapped NAV AI, chat with Dynamics NAV data, NAV MCP server

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json