How to add an AI chatbot to Microsoft Dynamics NAV
Short answer
Put a chat window on a web page, intranet or customer portal and connect it to NAV through read-only queries over web services or a replica. The bot retrieves the records, answers with citations, and can run on an open-weight model inside your network. NAV's own client does not need to change.
The NAV client is powerful but not friendly to casual users. A shop supervisor wants to know if a part is in stock; a sales rep wants an order status; a customer wants a shipment date. Today each of them waits for someone with NAV access or learns filters they will use twice a month.
A chatbot removes that gap. The difficult part is not the chat window but grounding: the bot must pull real records, show where each fact came from, and refuse when it cannot find evidence. It must also honor who is asking.
Because many NAV installs are on-prem and sensitive, this page leans toward a private deployment, with notes on when a simpler hosted option is enough.
What teams use it for
Shop floor stock questions
A supervisor types an item number or description on a tablet and gets quantity by bin or location, plus next receipt date.
Internal sales assistant
Reps ask for open orders, delivery dates and last prices for a customer, scoped to the accounts they own.
Customer portal order tracking
External customers sign in and ask where their orders are; the bot reads only their Sales Header and Shipment records.
Procedure and policy answers
Using retrieval over SOP documents, the bot answers how to process a return or when a quality hold applies, alongside NAV data.
Onboarding helper for new NAV users
Explains which page to open for a task, using your own training documents rather than generic NAV help.
Microsoft Dynamics NAV integration surface
- OData and SOAP page services for live lookups of items, orders, customers and vendors.
- Read-only SQL replica for aggregate or historical questions over ledger entries.
- Document sources outside NAV: SOP files, quality procedures and drawings on file shares or SharePoint, indexed for retrieval.
- NAV user and permission sets, which the bot can mirror to decide what a person may ask about.
- Customer-facing identity: if exposed externally, link portal users to Customer numbers in your own identity layer, not by giving them NAV logins.
How it works
- 1
Pick the audience first
Internal staff, shop floor or external customers have very different risk. Start with internal read-only.
- 2
Define the retrieval tools
Make a handful of functions: find item, get order, list open lines, search procedures. The model calls these rather than writing SQL.
- 3
Stand up the model
Serve an open-weight model on a GPU server with vLLM or Ollama, or use a hosted model if policy allows. Smaller models are enough for lookup chat.
- 4
Build the chat front end
A web widget in your intranet or portal, or a Teams tab. Show the records used under each answer.
- 5
Wire identity and permissions
Single sign-on to your directory; map users to allowed companies, customers or item groups before the tools run.
- 6
Test with real questions
Collect fifty questions from users, verify answers against NAV, and fix tools before launch.
Example flows
Supervisor checks a component
Trigger: Supervisor types: do we have bearing 6204 in stock?
- Bot searches the Item table for matching descriptions and asks which variant if several exist.
- It retrieves inventory by location and open purchase receipts.
- It replies with on-hand, reserved and expected dates.
- A link opens the item page for deeper detail.
Result: An answer in seconds with no NAV training needed.
Customer asks for a delivery date
Trigger: A signed-in customer asks about PO 77231.
- Bot resolves the customer number from the portal session.
- It finds the matching sales order by external document number.
- It reads shipment dates and carrier info.
- It answers, and escalates to a human if the order is not found.
Result: Fewer status emails to customer service, with strict data scoping.
Keeping data on-prem
A private chatbot works well on-prem. Run the model server, the retrieval index and the chat application on hardware inside your network, next to the NAV service tier or a replica. Staff reach it through the intranet or VPN. For customer-facing use, host only the thin chat application in a DMZ and let it call an internal API with narrow permissions, never the model or NAV directly. Open-weight models in the 7B to 70B range cover most lookup and summarization tasks, and your GPU budget decides the choice.
Security checklist
- Enforce per-user scoping in the tool layer, not in the prompt, because prompts can be bypassed.
- For external users, never use NAV credentials; use a separate identity and an allowlist of customer-scoped queries.
- Log questions and tool calls, and review them for abuse and leakage.
- Defend against prompt injection from document content by treating retrieved text as data, not instructions.
- Keep the bot read-only until you have trust and an approval design for actions.
Ways to get it done
Use Microsoft Copilot or a Power Virtual Agents style bot
Effort: Varies, but integration with NAV usually still needs custom connectors.
Mostly cloud, modern Microsoft shops; limited fit for older on-prem NAV.
Build with an open-source chat stack and your own tools
Effort: About 4 to 10 weeks for an internal pilot.
Teams with developers and GPU access wanting full control.
Netray-built private assistant
Effort: Pilot in several weeks, then widened by audience.
You want grounded answers, on-prem models and an audit trail without staffing it.
Pitfalls
- !Letting the model write SQL freely leads to wrong joins and leaks.
- !Skipping citations, so no one can trust or check an answer.
- !Duplicate or messy item descriptions cause wrong matches; clean search fields first.
- !Opening to customers before internal accuracy is proven.
- !Underestimating latency on CPU-only hosts.
Frequently asked questions
Can the chatbot live inside the NAV client?
Not easily on older versions. It is simpler to host it as a web page or Teams tab that sits beside NAV and calls its data. Later versions with web client control add-ins offer more embedding options.
Will it make up answers?
It can if left ungrounded. Require it to answer only from retrieved records, show the sources, and say it does not know otherwise. Test with trick questions before release.
Can customers use it?
Yes, with care. Use a separate identity layer, scope every query to the customer's own records, and escalate to people for anything ambiguous. Start internal first.
What hardware do we need on-prem?
For lookup chat, a single modern GPU server is often enough for a mid-size open model, depending on user count. Planning needs concurrency estimates, so size from real usage rather than guesses.
Does it replace NAV training?
It reduces basic lookups, but power users still need NAV for transactions. Treat the bot as a read-only front door and keep posting inside the system.
More for Microsoft Dynamics NAV
Want AI chatbot working on your Microsoft Dynamics NAV?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment