ml-connector
Microsoft Dynamics GPMicrosoft Dynamics 365 Sales

Microsoft Dynamics GP and Microsoft Dynamics 365 Sales integration

Microsoft Dynamics GP runs finance and receivables on-premises. Microsoft Dynamics 365 Sales manages your sales pipeline in the cloud. When a new account enters the sales pipeline, it needs to exist in Dynamics GP as a customer so credit limits and GL balances are visible to the team. This integration ensures customer records flow from Dynamics 365 Sales into Dynamics GP without manual entry, and pulls GL account balances and credit limits from Dynamics GP to give your sales team real-time visibility into customer financial standing.

How Microsoft Dynamics GP works

Microsoft Dynamics GP exposes customers, GL accounts, customer GL balances, and receivables invoices through Service Based Architecture (SBA) REST endpoints at https://<server>:<port>/GPService/Tenants(<TenantName>)/Companies(<CompanyName>)/<Module>/<Resource>, or through legacy SOAP Web Services. Authentication requires Windows domain credentials (Negotiate, Kerberos, or NTLM) mapped to a Dynamics GP user with appropriate role-based security. The system offers no webhooks, so all reads are by polling with ModifiedDate filters at customer-defined intervals, respecting the practical rate limit of the customer's SQL Server and the constraint that some entities do not have ModifiedDate fields. The integration must work against the customer's specific Dynamics GP version (2015, 2016, 2018, or 2025), as SBA coverage varies.

How Microsoft Dynamics 365 Sales works

Microsoft Dynamics 365 Sales exposes accounts, contacts, leads, opportunities, quotes, and sales orders through the Dataverse Web API at https://{org-name}.api.crm.dynamics.com/api/data/v9.2/ using OData v4.0 query syntax. Authentication uses OAuth 2.0 via Microsoft Entra ID with Client Credentials flow for server-to-server integration. The platform supports both webhooks via the Dataverse Event Framework (Create, Update, Delete) and polling. Webhooks are synchronous or asynchronous with a 60-second timeout and one automatic retry for 5xx errors. The webhook payload is limited to 256 KB and uses a shared secret for authentication rather than HMAC signatures. All credentials expire in approximately 60 minutes and must be refreshed.

What moves between them

Customer records flow from Microsoft Dynamics 365 Sales into Microsoft Dynamics GP. When an account is created or updated in Dynamics 365 Sales, ml-connector maps the account to a Dynamics GP customer entity with the account name, billing address, and contact information. GL account data flows the opposite direction: ml-connector polls Dynamics GP for the chart of accounts and customer GL balances, enriching Dynamics 365 Sales accounts with current receivables balance and credit limit so the sales team sees real financial standing. Reference data such as customer classifications and payment terms are maintained in both directions. The sync runs on a schedule aligned with the sales cycle and period-end close.

How ml-connector handles it

ml-connector stores Windows domain credentials encrypted and presents them on every REST or SOAP call to Dynamics GP using Windows authentication (Negotiate with fallback to NTLM). It polls Dynamics GP's SBA endpoint using ModifiedDate filters and handles the constraint that some entities do not carry ModifiedDate by polling by status or batch, respecting the 2-5 concurrent request limit and 100-200ms delays to avoid degrading end-user experience. Dynamics GP POST and PATCH payloads must wrap the data in a top-level Payload key, which ml-connector does automatically. For Dynamics 365 Sales, ml-connector refreshes the OAuth 2.0 token when it approaches the 60-minute expiry and accepts both webhook notifications for real-time account changes and fallback polling if webhooks are not enabled. It maps Dataverse account records to Dynamics GP customer entities using a deterministic key (account ID or name), validates that the target company database name is valid SQL syntax, and handles the read-only constraint that unposted Dynamics GP records can be modified but posted records cannot. GL balances read from Dynamics GP are stored as enrichment fields on Dataverse accounts so the sales team can see current receivables without switching systems. Every record carries an audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-market distributor runs Microsoft Dynamics GP on-premises for order-to-cash and finance, and uses Microsoft Dynamics 365 Sales for pipeline management across three regional sales teams. Before the integration, new accounts created in Dynamics 365 Sales had to be manually entered into Dynamics GP by the operations team before credit limits and receivables history could be viewed. Sales reps frequently contacted accounting to ask whether a prospect was creditworthy, causing delays. With the integration, accounts flow automatically from Dynamics 365 Sales into Dynamics GP within the polling cycle, and GL balances flow back to Dynamics 365 Sales so sales reps see current receivables and credit limit alongside the opportunity record. Account creation is instant from the sales team's perspective, and credit reviews are self-service.

What you can do

  • Sync accounts from Microsoft Dynamics 365 Sales into Microsoft Dynamics GP as customer records with address and contact details.
  • Push GL account balances and customer receivables totals from Dynamics GP into Dynamics 365 Sales accounts for sales team visibility.
  • Authenticate to on-premises Dynamics GP using Windows domain credentials over REST or SOAP with version-specific SBA coverage validation.
  • Poll Dynamics GP using ModifiedDate filters while respecting rate limits and handling entities that lack ModifiedDate fields.
  • Refresh OAuth 2.0 tokens for Dynamics 365 Sales and handle both webhook notifications and polling for real-time sync.

Questions

Does the integration support both REST and SOAP for Dynamics GP?
Yes. ml-connector can work with either Service Based Architecture REST endpoints or legacy SOAP Web Services, depending on what the customer's Dynamics GP instance supports. Verify with the customer which interface is available in their specific version (2015, 2016, 2018, or 2025) before deploying, since not all versions have full SBA coverage.
How does the integration handle Dynamics GP being on-premises while Dynamics 365 Sales is cloud?
ml-connector accepts the full on-premises server URL and port as a per-customer configuration and stores the Windows domain credentials encrypted. Every call to Dynamics GP is authenticated using Windows Negotiate (with NTLM fallback), so the integration works from any network as long as the customer exposes the Dynamics GP endpoint through the firewall with a valid SSL certificate or via a local agent.
What happens if a GL account is posted in Dynamics GP after the integration creates a receivables record?
Dynamics GP enforces a posted vs unposted constraint: once a record transitions from unposted (Work) to posted (Open or Historical), it becomes read-only. The integration reads GL balances and invoices from Dynamics GP in their current state and syncs them to Dynamics 365 Sales, but does not attempt to modify posted records. If a record is modified before posting, ml-connector will pick up the change on the next poll cycle using the ModifiedDate filter.

Related integrations

Connect Microsoft Dynamics GP and Microsoft Dynamics 365 Sales

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started