Microsoft Dynamics 365 Business Central and Zendesk integration

What moves between them

Master data flows from Microsoft Dynamics 365 Business Central into Zendesk: customers and vendors become Zendesk organizations, and their contact people become Zendesk users, so agents work against current account records. Account context such as the Business Central number, currency, payment terms, credit limit, and balance is carried into organization fields so it is visible on the ticket. A lighter flow runs the other way: when a Zendesk organization or user is created or corrected by an agent, ml-connector reads it back so the Business Central contact and address stay aligned. Nothing financial moves into Zendesk, because Zendesk has no invoice, purchase order, or general ledger object, so Business Central stays the financial system of record. The Zendesk organization external_id holds the Business Central record id so each ticket resolves to the correct account.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Business Central side it requests an Entra ID client credentials token for the api.businesscentral.dynamics.com scope and builds the base URL from the stored environment name and company id. On the Zendesk side it runs the OAuth2 authorization code flow against the customer's subdomain and sends the bearer token on every call, scoping each request to that subdomain since Zendesk has no global endpoint. Customers and vendors are matched to Zendesk organizations first, with the Business Central record id stored in the organization external_id and looked up through organizations search by external_id, so each ticket resolves to one account. It subscribes to Business Central change notifications for customers and vendors, answers the mandatory validation handshake by echoing the validationToken, verifies the clientState shared secret on each notification, renews every subscription before the three day expiry, and fetches the changed record because the notification carries no data. To capture agent edits, Zendesk organization and user webhooks subscribe to the event type directly, while a scheduled incremental export against start_time backfills anything a webhook missed and stays inside the ten request per minute export limit. User email is set on create only, since updating it in Zendesk adds a secondary address rather than replacing the primary, so the connector writes a contact email once and then matches on external_id. Neither system offers a shared idempotency key across these objects, so ml-connector dedupes on the Business Central number and the Zendesk id with a BullMQ jobId, uses the organizations and users batch endpoints with external_id as the upsert key, and respects cursor pagination so a re-read does not create duplicates. HTTP 429 on either side triggers backoff with jitter using the Zendesk Retry-After header, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized industrial equipment distributor with about three hundred staff runs Microsoft Dynamics 365 Business Central for finance, sales, and purchasing, and uses Zendesk for its customer support desk. Before the integration, when a customer opened a ticket about an order or a balance, the agent had to switch to Business Central and search by name to find the account, its credit limit, and whether it was on hold, and new accounts created in Business Central took days to show up in Zendesk. With Business Central and Zendesk connected, each customer and vendor becomes a Zendesk organization with its number, currency, payment terms, and balance on the record, and the contacts become Zendesk users, so the account context sits next to the ticket. Agents stop tab-switching and searching, and a new Business Central account appears as a Zendesk organization within the sync window instead of days later.

What you can do

• •Push Microsoft Dynamics 365 Business Central customers and vendors into Zendesk organizations and their contacts into Zendesk users.
• •Carry the Business Central number, currency, payment terms, credit limit, and balance into organization fields so account context shows on the ticket.
• •Anchor each Zendesk organization to its Business Central record through the external_id foreign key and organizations search.
• •Authenticate Business Central with Entra ID client credentials and Zendesk with OAuth2 on the customer subdomain.
• •React to Business Central change subscriptions and backfill from Zendesk by incremental export, with dedup, retries, and a full audit trail on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and Zendesk?

Mostly from Business Central into Zendesk. Customers and vendors become Zendesk organizations and their contacts become users, carrying account context onto the ticket. A lighter flow reads agent-created organizations and users back so the Business Central contact stays aligned. Nothing financial moves into Zendesk, because Zendesk has no invoice, purchase order, or general ledger object, so Business Central remains the financial system of record.

Zendesk has no invoices or GL accounts, so what actually syncs?

Zendesk holds support and account records, not financial ones, so ml-connector syncs the account masters it can store. Business Central customers and vendors map to Zendesk organizations, their contacts map to Zendesk users, and account details such as number, currency, payment terms, credit limit, and balance ride along in organization fields. The Zendesk organization external_id carries the Business Central record id so a ticket always resolves to the correct account.

How does the integration handle Business Central webhooks and Zendesk ticket events?

ml-connector subscribes to Business Central change notifications for customers and vendors, answers the required validation handshake, verifies the clientState shared secret, and renews each subscription before its three day expiry, then fetches the changed record since the notification carries no data. On the Zendesk side, organization and user events can subscribe to the event type directly, but ticket events fire only through a trigger or automation, so the connector also runs a scheduled incremental export against start_time to backfill reliably.