How to add WhatsApp to Microsoft Dynamics GP
Short answer
Dynamics GP has no WhatsApp feature, so you add a small middleware service. It reads order, shipment and payables data from the GP SQL Server databases, sends approved template messages through the WhatsApp Business Platform, and writes replies back through eConnect or a staging table that a clerk reviews.
Most Dynamics GP shops are distribution, light manufacturing or services companies that have run the same company database for ten or fifteen years. Customers and suppliers, however, now live on WhatsApp. Buyers ask 'where is my order' by message, suppliers confirm delivery dates by voice note, and your sales coordinators copy answers out of SOP Inquiry by hand.
GP is a Windows client over SQL Server, with a modest integration surface compared with a cloud ERP. There is no webhook framework and no native outbound messaging beyond email. That is not a blocker: the data is in plain, well-known tables, and the write side has a supported path in eConnect. What you need is a careful middleware layer that respects WhatsApp's template and consent rules.
This page covers the realistic design: what to read, what to send, how to take replies back in without bypassing GP business logic, and where on-prem GP servers complicate things.
What teams use it for
Order and shipment status for customers
A customer sends an order number and gets the current SOP status, ship date and carrier tracking, pulled from open and history sales tables. Cuts repetitive calls to order desk staff.
Delivery date confirmation from suppliers
When a purchase order in POP is released, the buyer's supplier receives a template message asking to confirm the promise date. A reply updates a review queue before anything changes in GP.
Past-due receivables nudges
Open receivables from the RM tables drive a polite reminder with invoice number and amount, sent only to contacts who opted in. Replies like 'paid on Friday' are routed to the collector.
Quote and price lookups for field sales
Salespeople message an item number and receive on-hand quantity by site and list price from item master and quantity tables, without opening GP remotely.
Approval pings for purchase requisitions
Approvers get a message with quick-reply buttons. The approval is recorded in your middleware and applied in GP by a user or service account, not by the message itself.
Microsoft Dynamics GP integration surface
- SQL Server company databases (default test company is TWO) hold the data. Useful read tables include SOP10100 and SOP30200 (sales header work and history), POP10100 (PO header), RM20101 (open receivables), IV00101 and IV00102 (item master and site quantities), and customer and vendor masters RM00101 and PM00200. Table and field names are stable across GP 2015 to 2018 and later, but verify on your build.
- eConnect is the supported .NET write interface. Stored procedures prefixed ta, such as taSopHdrIvcInsert, taPMTransactionInsert and taPopRcptHdrInsert, validate data against GP rules. It runs on a machine with GP components installed and a Windows service account.
- Web Services for Microsoft Dynamics GP (WCF) and, on recent versions, the service based architecture REST endpoints may be available. Their coverage and support status vary by version, so confirm with your partner before building on them.
- SmartList, SmartList Designer and Excel report exports can feed a nightly snapshot when a live database connection is not allowed.
- Direct inserts into GP tables bypass business logic and are unsupported for transaction data. Use SQL for reading and eConnect for writing.
How it works
- 1
Pick the WhatsApp channel
Use the WhatsApp Business Platform Cloud API directly or through a business solution provider. Register a business phone number, verify the business in Meta Business Manager and decide which templates you need.
- 2
Stand up middleware near GP
A small service (.NET fits eConnect best) that can reach SQL Server and also expose an HTTPS webhook for inbound messages. Put the public endpoint in a DMZ or behind a reverse proxy, never the SQL port.
- 3
Create a read-only SQL login
Grant select on the specific tables or, better, on views you define in a helper schema. Join SOP, POP and RM data there so the middleware never writes ad hoc queries against base tables.
- 4
Map phone numbers to GP contacts
GP stores phone numbers as free text in address and contact tables. Normalize to E.164 in your own mapping table and store opt-in status, timestamp and source there. GP is not the system of record for consent.
- 5
Register and approve message templates
Outbound messages outside the 24 hour customer service window must be pre-approved templates with variables for order number, date and amount. Keep a template per flow.
- 6
Handle inbound replies safely
Parse the reply, match it to a document, and write it to a staging table with a status. A human or a rule releases it. Only then call eConnect to update or create a GP transaction.
- 7
Log everything
Store message ids, template names, GP document numbers and the user who released each write so support can answer 'who changed this' later.
Example flows
Customer asks where an order is
Trigger: Inbound WhatsApp text containing a sales order number
- Webhook receives the message and matches the sender number to a customer in your mapping table.
- Middleware queries a view over SOP10100 and SOP30200 for that customer and document.
- It checks the document belongs to the sender's customer id before returning anything.
- It replies with status, requested ship date and tracking number if available.
Result: The customer gets an answer in seconds and the order desk is not interrupted for routine questions.
Supplier confirms a purchase order date
Trigger: Purchase order released in Purchase Order Entry
- Nightly or near-real-time poll picks up newly released POs from POP10100.
- A template message goes to the supplier contact with PO number and requested date.
- Supplier replies with a quick-reply button or a new date.
- Reply is written to a review queue; the buyer approves and the new date is entered in GP.
Result: Promise dates stay current and buyers see confirmations without email chasing.
Keeping data on-prem
Dynamics GP is very often installed on a local SQL Server with no inbound internet access, which suits this design. Keep the middleware inside the network, make only outbound HTTPS calls to the WhatsApp Cloud API, and receive inbound messages through a relay or reverse proxy that forwards to the middleware over a single locked-down port. If policy forbids even that, run a polling relay in the cloud that holds inbound messages and let the on-prem service pull them. Message content still passes through Meta's infrastructure, so keep pricing, margin and sensitive terms out of templates. Where a language model is used to interpret free-text replies, run an open-weight model locally so customer and vendor data does not leave your servers.
Security checklist
- Use a read-only SQL account scoped to views; never give the middleware sa or db_owner.
- Verify the sender's phone number maps to the customer before returning any document data.
- Validate WhatsApp webhook signatures and restrict the endpoint by IP and TLS.
- Keep consent records, and honour opt-out keywords immediately.
- Separate the eConnect service account from the read account and log every write with a user and timestamp.
Ways to get it done
Off-the-shelf messaging add-on
Effort: Days to a couple of weeks plus license cost
Works if a GP-compatible ISV product covers only simple alerts and you accept its data model. Check that it supports your GP version and on-prem SQL.
Build in-house on Cloud API and eConnect
Effort: Roughly one to three months for a first set of flows
Good if you have a .NET developer who knows GP and eConnect. Gives full control of flows and consent.
Partner such as Netray with a GP implementation partner
Effort: Typically weeks to a first pilot, depending on scope
Useful when you want conversational answers grounded in GP data, on-prem model hosting and human approval on writes.
Pitfalls
- !Phone numbers in GP are inconsistent. Without a cleaned mapping table you will message the wrong contact.
- !Using free-form messages outside the 24 hour window fails; every proactive message needs an approved template.
- !Writing replies directly into SQL tables corrupts balances and audit trails; always use eConnect or an approved import path.
- !Exposing SQL Server or a GP service to the internet for a webhook is an unnecessary risk. Use a relay.
- !Multi-company GP setups need the company database chosen explicitly per customer, otherwise lookups hit the wrong tenant.
Frequently asked questions
Does Dynamics GP have a native WhatsApp integration?
No. GP's built-in outbound options are email and printed documents. WhatsApp requires middleware that reads GP data and calls the WhatsApp Business Platform, with writes back to GP going through eConnect or another supported import path.
Can WhatsApp replies create transactions in GP automatically?
Technically yes through eConnect, but most finance teams prefer a staging queue with review. Auto-posting a message that says 'delivered' into receivings is risky when numbers or items are ambiguous.
Is the WhatsApp Business Platform free?
Pricing is per message category and country and changes over time, so check Meta's current rate card. Service replies inside the customer window are treated differently from proactive template messages.
Can this work with an on-prem GP server and no public IP?
Yes. Outbound calls to the Cloud API need only internet egress. For inbound, use a reverse proxy, a cloud relay that your server polls, or a business solution provider that exposes a pull model.
Do we need a business solution provider?
Not necessarily. The Cloud API can be used directly after Meta business verification. A provider helps with onboarding, number management and support, at an added monthly or per-message cost.
Want WhatsApp 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