Microsoft Dynamics NAV and Zendesk integration

What moves between them

Customer and vendor records flow from Microsoft Dynamics NAV into Zendesk. Customers from NAV map to organizations in Zendesk, bringing the customer name, billing address, phone, and custom fields like customer group or sales territory. Vendor contacts from NAV map to Zendesk users with roles and metadata marking them as vendor contacts. The sync runs on a schedule tied to your customer and vendor maintenance cycle, typically daily or weekly. NAV to Zendesk is the primary direction; Zendesk does not write financial or operational data back into NAV.

How ml-connector handles it

ml-connector uses OAuth2 client credentials to authenticate against your NAV tenant, accepts the full tenant-specific base URL for your NAV instance, and polls the OData v4 customers and vendors endpoints on your configured schedule. For each customer or vendor record, it extracts the key fields (name, address, phone, contact person), maps them to Zendesk organization or user fields, and creates or updates records in Zendesk via the Support API. When Zendesk sends webhook notifications for organization or user changes, ml-connector verifies the HMAC-SHA256 signature using the shared webhook secret. Because NAV webhook subscriptions expire after 3 days, the integration uses polling as the primary mechanism rather than relying on NAV webhooks. Custom fields in Zendesk organizations can store the NAV customer ID or vendor ID for bidirectional lookups. All records carry an audit trail showing when they were synced, what changed, and any errors encountered.

A real-world example

A small manufacturing company runs Microsoft Dynamics NAV for operations and finance, and Zendesk for customer support tickets. The support team historically spent time digging into separate systems to find customer contact information, billing addresses, and account history. With NAV and Zendesk connected, every customer who submits a support ticket appears as an organization in Zendesk with their latest name, address, phone, and custom fields like sales rep or customer tier. When a support agent opens a ticket from a customer, they immediately see the company profile and can reference the account without switching applications. Vendor portal inquiries also benefit: vendor contacts synced from NAV appear as Zendesk users, so support can confirm vendor status and contact details from a single view.

What you can do

• •Sync customer and vendor master records from Microsoft Dynamics NAV into Zendesk as organizations and users.
• •Map NAV customer fields (name, address, phone, contact person) to Zendesk organization attributes and custom fields.
• •Map NAV vendor contacts to Zendesk users with roles and metadata marking vendor status.
• •Authenticate NAV with OAuth2, poll NAV on a schedule, and verify Zendesk webhook signatures with HMAC-SHA256.
• •Maintain a full audit trail of every sync, including what changed, when it synced, and any errors.

Questions

Which direction does data move between NAV and Zendesk?

The primary flow is from Microsoft Dynamics NAV into Zendesk. Customer and vendor records from NAV sync into Zendesk as organizations and users, bringing their names, addresses, phone numbers, and contact details. Zendesk does not write operational or financial data back into NAV.

Why does the integration poll NAV instead of relying on NAV webhooks?

NAV webhooks expire every 3 days and must be manually renewed before they stop sending notifications, making them unreliable for production integrations. ml-connector uses polling as the primary mechanism on a schedule you control, such as daily or weekly, so customer and vendor changes are pulled from NAV on a predictable cadence without the risk of subscription expiry.

How does the integration handle Microsoft Dynamics NAV authentication and different deployment types?

ml-connector supports both cloud-based Business Central online and on-premises NAV installations. For cloud, it authenticates via OAuth2 client credentials against Microsoft Entra ID using the tenant-specific base URL. For on-premises, it can use either OAuth2 or basic authentication with a web service access key. You provide the appropriate credentials and base URL for your NAV instance during setup.