Microsoft Dynamics GP and Cleo integration

What moves between them

The main flow is Microsoft Dynamics GP into Cleo. Vendor master records and purchase order details from Dynamics GP are polled on a daily or weekly schedule and written to Cleo as EDI 850 transactions or structured JSON payloads to a dedicated folder. Cleo then distributes those records to trading partners via EDI or API. In the reverse direction, Cleo can push supplier shipment confirmations and invoice data back into Dynamics GP as receivables records when configured by the Cleo administrator, though that requires webhooks set up in Cleo Studio outside the REST API. The primary flow is outbound from Dynamics GP procurement to Cleo supply chain visibility.

How ml-connector handles it

ml-connector stores the Windows domain account credentials securely and presents them at the request layer when calling the customer's Dynamics GP Service Based Architecture REST endpoint. It refreshes the OAuth 2.0 Bearer token on Cleo before each write and handles 401 token-expired responses. Because Dynamics GP has no webhooks, ml-connector polls at customer-defined intervals using ModifiedDate filters on the vendor and purchase order entities to capture only changed records since the last run. Vendors are written to Cleo as a structured folder or file payload that the Cleo administrator can map to EDI 850 purchase order transactions; purchase orders are extracted with line-item detail (item code, quantity, promised date, cost center) and written as EDI 850 or a JSON structure. ml-connector respects Dynamics GP's unposted-only write constraint: only Work (draft) documents are created, never Posted or Historical records. It also enforces company-specific context (the SQL Server database name, not a human-readable name) and stays within the customer's defined GP version coverage (SBA availability varies by GP 2015, 2016, 2018, 2025). Every poll and write carries a job ID and full audit trail so vendor or PO records can be replayed if a Cleo downstream action fails.

A real-world example

A mid-sized industrial distributor runs Microsoft Dynamics GP for purchasing and payables, and uses Cleo Integration Cloud to orchestrate EDI transactions with suppliers and logistics carriers. Before the integration, the purchasing team created POs in Dynamics GP and manually exported them as CSV to Cleo, where the Cleo team reformatted them as EDI 850 transactions and sent them to suppliers via VAN or API. When suppliers updated shipment status in Cleo, that data sat in Cleo's folder structure until someone manually checked it and re-entered key dates into Dynamics GP to update the PO status. With Dynamics GP and Cleo connected, every new PO in Dynamics GP automatically flows into Cleo as an EDI 850 within an hour, suppliers receive it immediately, and when Cleo receives an inbound 856 shipment notice it can trigger a notification to Dynamics GP (if Cleo webhooks are enabled) so warehouse staff see the PO ready to receive without pulling reports.

What you can do

• •Poll Microsoft Dynamics GP vendors and purchase orders on a schedule and write them to Cleo as EDI 850 or structured JSON payloads.
• •Authenticate to Dynamics GP with Windows Active Directory credentials and to Cleo with OAuth 2.0 Bearer tokens.
• •Filter Dynamics GP records by ModifiedDate so only changed vendors and POs are synced on each poll, reducing volume and server load.
• •Preserve Dynamics GP unposted-document constraints and company-level context so POs stay in draft status and link to the correct company database.
• •Maintain an audit trail with job IDs on every poll and write, so any record can be replayed if a downstream Cleo action fails.

Questions

How does ml-connector handle the difference between Dynamics GP polling and Cleo's pull-based architecture?

Dynamics GP has no webhook capability, so ml-connector polls the Dynamics GP endpoint on a customer-defined schedule (daily or weekly), using ModifiedDate filters to capture only changed vendors and POs since the last run. Those records are then written to Cleo as files or EDI 850 transactions that the Cleo administrator can further distribute to trading partners. Cleo's outbound push to Dynamics GP requires CIC Studio configuration outside the ml-connector API.

What Windows credentials and SQL Server context does ml-connector need to access Dynamics GP?

ml-connector requires a Windows domain account created in the customer's Active Directory and configured as a Dynamics GP User with the appropriate role-based security for reading vendors and purchase orders. The account is stored encrypted and used on every request to the Dynamics GP Service Based Architecture endpoint at the customer's server and port. The Dynamics GP company name is the actual SQL Server database name, not a human-readable name, so ml-connector must be configured with the exact database name for the company scope.

What happens if a purchase order in Dynamics GP is already posted or if the fiscal period is closed?

Dynamics GP only allows write operations on unposted (Work) documents; ml-connector respects that constraint and never attempts to create or modify Posted or Historical records. If ml-connector needs to create a new PO in Dynamics GP from a Cleo event, it only creates Work-status (draft) documents. Similarly, if the target fiscal period is closed in Dynamics GP, the write will fail with a validation error, and ml-connector will surface that error in the audit trail so you can address it before replaying.