# How to add an AI chatbot to Microsoft Dynamics NAV > Source: https://netray.co/integrations/dynamics-nav-ai-chatbot > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## 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. ## System Microsoft Dynamics NAV ## Capability ai-chatbot ## Intro 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. ## Use Cases ### Shop floor stock questions **Description:** 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 **Description:** Reps ask for open orders, delivery dates and last prices for a customer, scoped to the accounts they own. ### Customer portal order tracking **Description:** External customers sign in and ask where their orders are; the bot reads only their Sales Header and Shipment records. ### Procedure and policy answers **Description:** 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 **Description:** Explains which page to open for a task, using your own training documents rather than generic NAV help. ## System 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 ### Pick the audience first **Detail:** Internal staff, shop floor or external customers have very different risk. Start with internal read-only. ### Define the retrieval tools **Detail:** Make a handful of functions: find item, get order, list open lines, search procedures. The model calls these rather than writing SQL. ### Stand up the model **Detail:** 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. ### Build the chat front end **Detail:** A web widget in your intranet or portal, or a Teams tab. Show the records used under each answer. ### Wire identity and permissions **Detail:** Single sign-on to your directory; map users to allowed companies, customers or item groups before the tools run. ### Test with real questions **Detail:** 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? **Steps:** - 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. **Steps:** - 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. ## 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 - 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. ## Options ### Use Microsoft Copilot or a Power Virtual Agents style bot **Fit:** Mostly cloud, modern Microsoft shops; limited fit for older on-prem NAV. **Effort:** Varies, but integration with NAV usually still needs custom connectors. ### Build with an open-source chat stack and your own tools **Fit:** Teams with developers and GPU access wanting full control. **Effort:** About 4 to 10 weeks for an internal pilot. ### Netray-built private assistant **Fit:** You want grounded answers, on-prem models and an audit trail without staffing it. **Effort:** Pilot in several weeks, then widened by audience. ## 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. ## Faq ### Can the chatbot live inside the NAV client? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms dynamics nav chatbot, ai chatbot for dynamics nav, navision chatbot, dynamics nav virtual assistant, chat with dynamics nav data, dynamics nav on-prem chatbot, dynamics nav customer portal chatbot, dynamics nav natural language --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json