# How to add AI agents to Microsoft Dynamics GP > Source: https://netray.co/integrations/dynamics-gp-ai-agents > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## Short answer Build AI agents on GP by giving them a narrow tool layer: read-only SQL views over the company database for lookups, and eConnect or Integration Manager for writes that a person approves. Keep the model on your own servers if the data cannot leave. Start with one workflow such as purchase order follow-up or AP exception triage. ## System Microsoft Dynamics GP ## Capability ai-agents ## Intro Many Dynamics GP shops are mid-size manufacturers and distributors that have run the same GP install for ten or fifteen years. The system is stable, heavily customised through Report Writer, SmartList Builder, VBA and Dexterity add-ons, and usually hosted on a Windows Server with SQL Server in the same building. Nobody wants to rip it out for an agent project. An AI agent in this context is not a chatbot. It is a worker that takes a goal, such as chase every purchase order that is late for a key item, calls a handful of tools against GP, drafts the result and waits for a person. GP gives you a good foundation for that: the data lives in plain SQL Server tables with predictable names, and there are supported paths for posting transactions. The caution is that GP has a long lifecycle announcement and many teams are weighing a move to Business Central. An agent layer that talks to GP through a thin tool interface survives that move, because only the tool implementations change, not the agent logic. ## Use Cases ### Late PO expediting **Description:** An agent reads open purchase order lines from the POP tables, compares promise dates with the item's demand, groups by vendor and drafts a short follow-up email per vendor for a buyer to approve. ### AP invoice exception triage **Description:** Three-way match failures in Payables are explained in plain language: price variance versus the PO, quantity over receipt, or a vendor ID mismatch. The agent proposes the fix and routes it to the right clerk. ### Credit hold review **Description:** Before a sales order batch is released, the agent pulls customer balance, aging buckets and credit limit from Receivables Management and writes a one-paragraph recommendation for the credit manager. ### Inventory shortage watch **Description:** Each morning the agent checks item quantities by site against open sales order demand and flags items likely to short, with the open POs that could cover them. ### Month-end close checklist **Description:** The agent walks unposted batches, unreconciled bank transactions and open subledger differences, then produces a prioritised list for the controller instead of someone running five SmartLists. ## System Surface SQL Server company databases: one database per GP company plus the DYNAMICS system database. Typical tables are RM00101 (customers), PM00200 (vendors), IV00101 (item master), IV00102 (item quantities by site), POP10100 and POP10110 (PO header and lines), and SOP10100 and SOP10200 for sales documents in work. Confirm names against your version. eConnect: the long-standing .NET and SQL stored procedure interface for creating transactions such as sales orders, payables invoices and inventory adjustments. Check the support status for your GP version before building on it. Web Services for Microsoft Dynamics GP: an older SOAP or WCF service layer with security tied to GP roles. Availability and support differ by version, so verify before depending on it. Integration Manager and Microsoft Dynamics GP import tools, which can post from files or SQL sources with GP business logic applied. Useful for approved write-backs when eConnect is not an option. GP security: users, security roles and tasks defined in the application, and SQL logins. An agent service account should map to a deliberately limited role. ## How It Works ### Pick one workflow and list the questions it needs **Detail:** Do not start with open-ended access. Write down the five or six data questions a buyer or clerk asks to do the job today, and the one write action that follows. ### Create read-only SQL views **Detail:** In a separate schema on the GP SQL Server, define views such as open PO lines with vendor and item, or customer aging. Grant a dedicated SQL login select on those views only, never on the base tables. ### Wrap each view in a typed tool **Detail:** Expose tools like get_open_po_lines(vendor_id, days_late) with strict parameter types and row limits. The agent never writes SQL against raw GP tables. ### Add a write tool that only proposes **Detail:** A propose_po_change tool stores the intended change in a queue table with the evidence. A person approves in a simple screen, and only then does a separate service call eConnect or Integration Manager. ### Run the model where the data is **Detail:** Serve an open-weight model with vLLM or Ollama on a GPU server beside the SQL Server, or use a private cloud endpoint if policy allows. ### Log every tool call **Detail:** Keep the prompt, tool name, arguments, row count and result hash so auditors can replay what the agent saw and why it recommended something. ## Example Flows ### Vendor chase for late purchase orders **Trigger:** Scheduled each weekday at 7am. **Steps:** - Agent calls the open PO lines tool for lines past promise date. - It joins item demand for the next 14 days and ranks by shortage risk. - It drafts one email per vendor listing PO numbers, lines and the date needed. - Buyer reviews drafts in a queue and approves or edits. **Result:** Buyers send ten reviewed vendor emails instead of building them by hand from a SmartList. ### Payables hold explanation **Trigger:** A clerk asks why an invoice is on hold. **Steps:** - Agent looks up the payables transaction and its batch. - It reads the related PO lines and receipts. - It compares quantities and unit prices. - It returns the specific mismatch and a suggested next step. **Result:** The clerk resolves the exception in minutes without hunting through inquiry windows. ## On Prem GP is very often on-premises, so the agent stack can be too. Put the tool service, a small vector or cache store and the model server in the same network segment as the SQL Server, reach GP data through read-only views, and keep all prompts and logs inside the firewall. A single modern GPU server running a mid-size open-weight model is usually enough for a few concurrent agent runs. If the site is fully air-gapped, ship model weights and updates on approved media and disable any outbound calls in the agent framework. ## Security - Dedicated SQL login with select on a view schema only, no access to system tables or the DYNAMICS database. - Write actions go through a human approval queue and use a service account mapped to a limited GP role. - Row limits and parameter allow-lists on every tool to prevent bulk exfiltration through prompt injection. - Treat vendor and customer text fields as untrusted input, since a note can contain instructions aimed at the model. - Full audit log of prompts, tool calls and approvals retained under your own retention policy. ## Options ### Microsoft Copilot or Dynamics 365 features **Fit:** Better fit if you are already moving to Business Central, as GP itself has limited native AI. **Effort:** Low, but tied to a migration decision. ### Build in-house with a Python or .NET agent framework **Fit:** Good if you have a developer who knows GP tables and SQL Server administration. **Effort:** A few weeks for one read-only workflow, longer for approved write-back. ### Work with a partner such as Netray **Fit:** Useful when you want a private model, a tested tool layer and a GP-aware reviewer for the first workflows. **Effort:** Typically a short pilot on one workflow, then expansion. ## Pitfalls - Pointing the agent at base tables: custom fields and multi-currency columns make raw joins easy to get wrong. Use curated views. - Ignoring unposted versus posted data: work tables and history tables hold the same document at different stages. - Letting the agent write directly to tables. Always go through eConnect, Integration Manager or another supported posting path. - Multi-company sprawl: each company is a separate database, so tools must take an explicit company parameter. - No evaluation set: save twenty real questions and expected answers before changing models or prompts. ## Faq ### Can an AI agent write transactions into Dynamics GP? **Answer:** Yes, but through a supported path such as eConnect or Integration Manager rather than direct SQL inserts. Best practice is that the agent proposes a change, a person approves it, and a separate posting service performs the write using a limited GP role. ### Do we need the cloud to run agents on GP? **Answer:** No. Because GP data sits in SQL Server on your network, the agent tools and an open-weight model can run on a local GPU server. Cloud models are an option if your data policy allows, but they are not required. ### Which GP versions work? **Answer:** The SQL read path works across most modern versions because it relies on table structures that have been stable for years. Write paths and web services vary by version, so confirm eConnect or service support for yours before committing. ### What is the safest first agent? **Answer:** A read-only one, such as late PO follow-up drafts or an AP hold explainer. It touches no transactions, proves the data layer, and gives users a concrete result before you add any write-back. ### Will this still work if we move to Business Central? **Answer:** The agent logic and approval workflow carry over. You would replace the GP tool implementations with Business Central API calls, so keep the tool names and parameters generic from the start. ## Search terms dynamics gp ai agents, ai agents for microsoft dynamics gp, dynamics gp automation ai, great plains ai agent, dynamics gp purchase order automation, dynamics gp econnect ai, add ai to dynamics gp, on-prem ai agents dynamics gp, dynamics gp copilot alternative, dynamics gp ap exception automation --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json