# Zendesk Salesforce integration

*Zendesk → Salesforce*

**In short:** A Zendesk to Salesforce integration keeps support and revenue in one picture: each Zendesk ticket becomes (or updates) a Salesforce Case, Zendesk users and organizations are matched to Salesforce Contacts and Accounts, and CSAT, tags, and SLA breaches land on the right record so account owners see support reality without opening Zendesk. Done properly it is not a point-to-point app toggle: it is an idempotent, near-real-time pipeline that resolves identity across both systems, maps custom fields both ways, and never creates a duplicate Contact or Case.

## 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.

## Frequently asked questions

### Can't I just use the native Zendesk for Salesforce app from the marketplace?

For a simple, one-directional view of tickets inside Salesforce, the marketplace app is often enough and we will say so. It starts to strain when you need reliable two-way sync, custom-field mapping on both sides, deduplication against an existing Salesforce Contact base, or per-Account routing rules. At that point you are maintaining brittle config in two admin consoles instead of owning one pipeline with a clear contract, and every Zendesk or Salesforce API change becomes your team's fire drill.

### How do you stop duplicate Contacts and Cases from being created?

Identity resolution is the core of the build. A Zendesk user is matched to a Salesforce Contact by email first, then by an external-id you store on both sides, never by name. The Zendesk ticket id is written to an external-id field on the Salesforce Case so a re-sync updates the existing Case instead of creating a second one. Every write is idempotent and keyed on a stable identifier, so retries and replays never duplicate a record.

### Can it sync both ways - Salesforce back into Zendesk?

Yes, where it earns its place. Common patterns are pushing Salesforce Account tier or entitlement into Zendesk organization fields so agents see who they are talking to, and writing Case status or owner changes back to the ticket. We scope which fields are authoritative in which system up front, because a field that both systems can edit needs a defined winner to avoid a sync loop overwriting real work.

### What about Zendesk custom fields and Salesforce custom objects?

They are the normal case, not the exception. Ticket forms, custom ticket fields, tags, and Salesforce custom fields or custom objects are mapped explicitly during scoping. We agree the exact field-to-field mapping, the value transformations (a Zendesk dropdown value to a Salesforce picklist API name), and what happens when a value has no target, then encode that in the pipeline rather than leaving it to a marketplace app's fixed schema.

### Who operates it after go-live, and what about the Salesforce API limits?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor, and it is built to respect Salesforce's daily API request limits and Zendesk's rate limits - batching writes with the Bulk or Composite API and backing off on 429s rather than burning your org's quota. If Zendesk or Salesforce changes an API, that is our contractual problem to fix. You get a named owner, alerting, incident response, and an SLA.

## Related integrations

- [Intercom ↔ Salesforce](https://seamless.engineering/integrations/intercom-salesforce/): Intercom Salesforce integration
- [Salesforce ↔ Jira](https://seamless.engineering/integrations/salesforce-jira/): Salesforce Jira integration
- [ServiceNow ↔ Salesforce](https://seamless.engineering/integrations/servicenow-salesforce/): ServiceNow Salesforce integration
- [Zendesk ↔ HubSpot](https://seamless.engineering/integrations/zendesk-hubspot/): Zendesk HubSpot integration
- [Zendesk ↔ Jira](https://seamless.engineering/integrations/zendesk-jira/): Zendesk Jira integration
- [Zendesk ↔ Slack](https://seamless.engineering/integrations/zendesk-slack/): Zendesk Slack integration

## Browse by system

- [All Zendesk integrations](https://seamless.engineering/integrations/zendesk/)
- [All Salesforce integrations](https://seamless.engineering/integrations/salesforce/)
- [Zendesk API changelog](https://seamless.engineering/api-changelog/zendesk/): 0 breaking changes and 2 deprecations in the last 90 days
- [Salesforce API changelog](https://seamless.engineering/api-changelog/salesforce/): No breaking changes or deprecations in the last 90 days

## Request a scoping call

Need this integration built and permanently operated? Tell us which systems connect and what data has to move. Fixed-price scoping quote within 48 hours.

- Email: hello@seamless.engineering
- Contact form: https://seamless.engineering/#contact