How to add an AI chatbot to Microsoft Dynamics GP
Short answer
A GP chatbot answers questions from live SQL data and your own documents, shows where each answer came from, and respects who is asking. Host it as an intranet page, a Teams bot or a customer portal widget. It can run entirely on-prem with an open-weight model.
Dynamics GP users know the pain of inquiry windows. To answer a simple question like where is PO 4521 or what do we owe this vendor, someone opens a lookup, picks filters and reads a grid. Casual users never learn the screens, so they ask the one person who does, and that person becomes a bottleneck.
A chatbot removes that middle step. The useful ones are not generic: they are grounded. Each answer comes from a query or a document, with the source displayed, so the user can trust and check it. That is also what keeps the model from inventing a balance.
This page is about the chatbot as a product for people, whether staff or customers, not the plumbing. If you want the tool protocol underneath, see the MCP page for GP.
What teams use it for
Staff help desk for GP questions
Buyers, planners and accountants ask for order status, balances and item data in plain language, without learning inquiry windows.
Customer order status portal
Customers ask where their order or invoice stands. The bot reads a sanitised view of sales documents tied to their account only.
Vendor self-service
Suppliers ask whether an invoice has been received and when payment is scheduled, answered from payables data without calling AP.
How do I do this in GP
Searchable answers from internal procedures and user manuals, such as how to void a posted receipt, with a link to the exact document.
Sales rep quick facts
Credit status, last order date, price level and open quotes for a customer, available from a phone chat window before a call.
Microsoft Dynamics GP integration surface
- Read-only SQL views over customers, vendors, items, PO and sales documents, which feed answers about balances, orders and stock.
- Document sources such as SOPs, training PDFs, and exported Report Writer descriptions, indexed in a private vector store.
- GP users and security roles, mapped to chatbot roles so a clerk and a sales rep see different data.
- Customer and vendor IDs from RM and PM records as the key for portal row-level filtering.
- Front-end options: an intranet page, a Teams app, or a web widget on an existing customer portal. GP has no embedded chat surface, so this is always an adjacent app.
How it works
- 1
Choose the first audience
Internal staff is safest. External customers need row-level isolation and legal review before launch.
- 2
Build the data tools
Create SQL views and typed query functions for the top fifteen questions. The model chooses a function; it does not write free SQL.
- 3
Index documents
Chunk SOPs and manuals, attach metadata such as module and version, and store embeddings locally. Cite the document title and section in answers.
- 4
Identity and roles
Sign users in with your identity provider, map them to chatbot roles, and pass a customer or vendor ID filter that the model cannot override.
- 5
Design the answer format
Show a short answer, a small table where useful, and a source line naming the view or document with the query time.
- 6
Pilot, measure and tune
Run with ten users, review logged questions weekly, and fix retrieval gaps and unclear answers.
Example flows
Buyer asks about a purchase order
Trigger: Buyer types: Has PO 4521 been received?
- Bot calls the PO status function for that number.
- It reads lines, quantities received and promise dates.
- It replies with lines still open and the vendor contact.
Result: Answer with source in seconds, no inquiry window needed.
Customer asks where an invoice is
Trigger: Customer logs into the portal and asks about invoice status.
- Bot receives customer ID from the session, not from the prompt.
- It queries receivables for that customer only.
- It shows invoice date, amount due and payment status.
Result: Fewer status calls to the accounting team.
Keeping data on-prem
The whole chatbot can sit inside your network. Run an open-weight chat model and an embedding model on a local GPU server, keep the vector store on disk beside the SQL Server, and serve the interface from your intranet. For external customers, put only the chat interface and a narrow API behind your DMZ and keep the model and data layer internal. Smaller models are fast and good enough for lookups and policy questions, but give them structured tools, because they handle free-form numerical reasoning less reliably.
Security checklist
- Row-level filters set by the application from the logged-in identity, never by the model.
- Separate indexes for internal and external documents so a customer query cannot retrieve internal procedures.
- Redact bank details, tax IDs and cost data from external-facing views.
- Rate limit and log conversations, with a retention policy that matches your privacy obligations.
- Clear disclosure that users are talking to an AI, and an escalation route to a human.
Ways to get it done
Microsoft Copilot Studio or a generic chatbot builder
Effort: Low for documents, more for live data.
Works for documentation Q&A, but still needs a data bridge to on-premises GP.
Build in-house with open-source RAG tooling
Effort: A few weeks to a usable internal pilot.
Fits teams with developers who can maintain retrieval quality and views.
Netray-built private chatbot
Effort: Pilot on one audience and ten to fifteen question types.
When data must stay local and you want GP-aware tools and role handling.
Pitfalls
- !Letting the model compute totals from a table dump. Return computed figures from SQL.
- !Launching to customers first. Start internal to learn what questions arrive.
- !Stale documents in the index leading to out-of-date procedures. Add version and review dates.
- !No fallback. If the bot cannot answer, say so and offer a person.
- !Overlooking multi-company, so the same customer ID returns results from the wrong entity.
Frequently asked questions
Can the chatbot live inside the GP client?
Not natively. GP does not provide an embedded chat surface, so the chatbot runs as an adjacent web page, Teams app or portal widget. Some teams link to it from a GP shortcut or a custom menu through Modifier or add-ins.
Will it make up numbers?
It can if you let it. The defence is grounding: numbers come from SQL functions, the answer shows its source, and unanswerable questions return a clear refusal. Test with questions whose correct values you already know.
Can customers use it safely?
Yes with care. Identity must come from the authenticated session, data must be filtered in code by customer ID, and external views should exclude cost, margin and internal notes. Have legal and security review it first.
What hardware does an on-prem chatbot need?
For a few dozen internal users, one server with a modern data-centre GPU running a mid-size open-weight model is a common starting point. Needs rise with concurrency and model size, so size from a pilot rather than guessing.
Is Microsoft's own AI enough?
For documents and Microsoft 365 content, often yes. For live on-premises GP data, you still need a custom data bridge, so a Microsoft tool alone usually does not answer ledger or order questions.
More for Microsoft Dynamics GP
Want AI chatbot working on your Microsoft Dynamics GP?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment