Zendesk Salesforce integration

What a Zendesk to Salesforce integration actually does

Zendesk is where support lives: the ticket, the conversation, the CSAT score, the SLA clock, the tags your agents apply. Salesforce is where the customer relationship lives: the Account, the Contact, the open opportunity, the renewal date, the account owner. The two describe the same customers from different sides, and by default neither can see the other.

A Zendesk to Salesforce integration closes that gap. It takes each relevant support event in Zendesk and expresses it on the right Salesforce record: a ticket becomes a Case linked to the correct Account and Contact, a satisfaction rating and SLA breach surface where the account owner already works, and a spike of tickets on a key Account is visible to the person carrying the renewal. Done well, nobody in sales opens Zendesk to know a customer is in trouble, and nobody in support opens Salesforce to know a ticket comes from a strategic Account.

What data moves

Zendesk object / event	Becomes in Salesforce	Notes
Ticket created / updated	Case (created or updated)	Zendesk ticket id stored on a Case external-id field for idempotent upserts
Ticket comments	Case Comments / Feed items	Public vs internal notes mapped separately; attachments referenced
Zendesk user (requester)	Contact	Matched by email, then external-id - never created blind
Zendesk organization	Account	Mapped to an existing Account where one exists, not duplicated
Ticket status / priority	Case Status / Priority	Value transformation from Zendesk fields to Salesforce picklist API names
Satisfaction rating (CSAT)	Case field / custom field	Score and comment land on the Case and roll up to the Account
SLA policy breach	Case flag / Task	Surfaces a breached SLA to the account owner
Ticket tags & custom fields	Case custom fields / picklists	Explicit field-to-field mapping agreed during scoping

The exact field mapping, the authoritative system for each field, and the value transformations are agreed once during scoping and encoded in the pipeline. After that, nobody re-maps them by hand.

The details that break naive syncs

A marketplace app or a quick middleware recipe gets you the demo and leaves the expensive edge cases in production:

• Identity matching. The whole integration is only as good as its ability to say “this Zendesk user is that Salesforce Contact.” Matching on name creates duplicates the first time someone has two email addresses. It has to key on email, then on a stored external-id, with a defined rule for what happens when there is no match - create, queue for review, or skip.
• Duplicate Cases. Re-run a naive sync and every open ticket spawns a second Case. The Zendesk ticket id must be written to the Salesforce record so a re-sync upserts the existing Case instead of creating a new one.
• Field and picklist mapping. A Zendesk priority, a custom dropdown, or a ticket form field does not line up one-to-one with a Salesforce picklist. Values need explicit transformation to the Salesforce API names, and a defined fallback when a value has no target on the other side.
• Two-way authority. If both systems can edit status or owner, a naive bidirectional sync loops: each write triggers the other, overwriting real changes. Each field needs one authoritative system and a clear direction of travel.
• API limits. Salesforce enforces a daily API request limit per org and Zendesk enforces rate limits. A row-by-row sync burns through both. Writes have to be batched through the Bulk or Composite API and back off cleanly on a 429 rather than failing the run.
• Partial failures and ordering. A batch of 500 ticket updates where 3 fail cannot roll the other 497 back or silently drop the 3. Failures go to a dead-letter queue, get retried, and out-of-order events (an update arriving before its create) are handled without losing data.

How we build and run it

We treat this as a pipeline, not a pair of connector toggles. Zendesk ticket, user, and organization events are received by webhook or pulled on a schedule, validated, resolved against Salesforce identity, transformed into your agreed field mapping, and written through the Salesforce Bulk or Composite API - with Case, Contact, and Account upserts keyed on stable external ids.

The pipeline is idempotent: every Zendesk event carries a stable identifier, and every Salesforce write is an upsert on an external-id, so a retry or a replay never creates a duplicate Case or Contact. It runs on cloud-native, fully EU-hosted AWS infrastructure, so ticket and customer data never leaves the EU - which keeps your DPA / AVV and GDPR obligations clean, a real concern when support conversations contain personal data.

And then we keep it running. Monitoring, alerting, incident response, and - critically - watching for Zendesk and Salesforce API changes are our responsibility under contract. When Salesforce deprecates an API version or Zendesk changes a webhook payload, that is our fire drill to run before it reaches you. You get a named owner and an SLA, not a recipe somebody has to babysit.

When this integration is worth building

If you have a small support volume and just want agents to see tickets inside a Salesforce tab, the native marketplace app is genuinely fine and we will tell you so. The managed pipeline earns its place when the stakes climb: when you need reliable two-way sync with clear field authority, when an existing Contact and Account base makes deduplication non-negotiable, when custom fields and objects on both sides have to map exactly, or when support signal - CSAT drops, SLA breaches, ticket spikes on strategic Accounts - has to reach the people who own the revenue in near real time and be trusted. At that point you want one pipeline with an owner, not brittle config spread across two admin consoles.