AdvancedMicrosoft Dynamics NAVData access / Web services / SQL Server / Permissions

Adding a Private AI Layer to Dynamics NAV On-Prem

Question
how to add AI to Dynamics NAV on-prem

Also searched as

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

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.

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

How to stand up a private AI layer on NAV

  1. 1List the questions to answer first: item availability, open sales and purchase lines, customer ledger balances, production orders, serial and lot traceability.
  2. 2Make 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.
  3. 3Generate 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.
  4. 4Publish 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.
  5. 5Index attachments, item descriptions, comments and external documents referenced from NAV records into a local retrieval store.
  6. 6Expose read actions through a tool server with strict parameter validation and a row limit, and log every call.
  7. 7Serve the model with vLLM or Ollama on local GPUs and run a ten-user read-only pilot before enabling any drafts.

Real data access paths in NAV

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.

-- 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

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

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

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.

Try it here, free

Dynamics NAV AI Assistant Sizing and Value Calculator

Open full tool

Work out the GPUs, index size and monthly value of a private AI assistant on NAV from your users and question volume.

Common 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.

How an ERP-grounded AI assistant handles this

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.

See ERPray

Frequently asked questions

Does NAV need to be upgraded before adding AI?

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?

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?

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?

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.

Related

Advanced

Adding a Private AI Layer to Business Central On-Premises

Business Central on-premises has a clean, supported read path: API v2.0, custom API pages written in AL, and OData web services, all enforcing the calling user's permissions. Put a tool server on top of those, add a retrieval index and an open-weight model on your own GPUs, and keep write-back behind human approval and the same APIs.

Advanced

Adding a Private AI Layer to Dynamics AX 2012 On-Prem

You can put a useful AI assistant on Dynamics AX 2012 without sending anything to a cloud: read from a SQL Server replica, expose a short list of approved read actions through a tool server, serve an open-weight model on local GPUs, and mirror AX security roles so answers respect what each user may see. Write-back stays human-approved and goes through AX services, never direct SQL.

How-to

Calling and extending the Business Central API v2.0

The Business Central API v2.0 is a REST/OData endpoint at api.businesscentral.dynamics.com/v2.0/{tenant}/{environment}/api/v2.0, authenticated with Azure AD OAuth 2.0. It exposes standard entities like customers and items, and lets you publish your own with an AL API page.

Advanced

Adding a Private AI Layer to an SSRS Report Estate

An SSRS estate holds years of business logic in RDL files, shared datasets and subscriptions. A private AI layer can make that estate searchable (which report answers this question), run reports with parameters on the user's behalf, and summarise the output, all on your own servers while keeping SSRS folder security and data source credentials in force.

Error fix

Fixing "Cannot create a record in (table). The record already exists" in D365 F&SCM data entity imports

This is the standard kernel duplicate-key exception, thrown when the Data Management Framework tries to insert a staging row into a target table whose unique or alternate key already matches an existing record. It almost always means the entity's insert-vs-update logic did not recognize the target row as an update, not that you have a true accidental duplicate in your source file.

Error fix

Fixing "There are currently no batch servers available for processing" in D365 F&SCM

This message means the batch framework cannot find any AOS instance flagged as a batch server and available for the batch group the job is assigned to. The fix is almost always in server configuration (System administration > Servers) or batch group assignment, not in the batch job itself.

AI for ERP

AI for Dynamics GP and NAV, Before the Business Central Decision

Dynamics GP mainstream support is ending and NAV is long retired from active development. Add a private LLM over GP or NAV data now, on-prem, without a forced Business Central move.

AI for ERP

AI Agents for ERP, Running On-Prem

A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.

Stuck on Microsoft Dynamics NAV?

Talk to engineers who work inside Microsoft Dynamics NAV every week, and who build private AI that answers these questions from your own ERP data.

Talk to an ERP engineerBrowse ERP Help
All ERP Help articles

Keep exploring

Free tools

ERP fixes and how-tos

AI on your ERP

Integrations

Software

TermsDynamics 365 Business Central