Zendesk Salesforce Integration: What Syncs, Setup, and Limits

Zendesk's integration resources page lists the pieces you turn on separately after connecting a Salesforce organization: ticket view in Salesforce, ticket sync from Zendesk to Salesforce, the Salesforce app for Zendesk Support, data sync from Salesforce to Zendesk, a multiple organizations feature, and an integration log for monitoring. It is available on Zendesk Suite Team, Growth, Professional, Enterprise, and Enterprise Plus, and on Support Team, Professional, and Enterprise. On the Salesforce side you need an edition with API rights: Performance, Unlimited, Enterprise, Developer, or Professional with the API add-on. People searching for the Salesforce integration for Zendesk v2 usually mean this current built-in integration (the connected app it creates in Salesforce is named Salesforce Integration for Zendesk) as opposed to the older AppExchange package, and the Zendesk endpoints behind it live under /api/v2. There is no separate thing to buy: the integration is included and configured from Admin Center.

Setup starts in Zendesk Admin Center under Apps and integrations, then Integrations, then Salesforce. Click Add connection, choose Production or Sandbox, accept the terms, and sign in to Salesforce. You must be a Zendesk Support administrator and a Salesforce administrator, and Zendesk is explicit that an API-only Salesforce user cannot be used for the connection. Two settings trip people up. First, Salesforce session settings must not lock sessions to an IP address, or the integration disconnects. Second, if the admin who authenticated the connection is later downgraded, the integration stops working until another admin reconnects it, so connect with a service-style admin account rather than a person who might change roles. Zendesk recommends testing with sandbox environments on both sides before touching production, and one Salesforce org connects to one Zendesk account, though multiple Salesforce orgs can connect to a single Zendesk instance.

Ticket view is the lightest option. You install a managed package from Admin Center that adds a Lightning component and a Visualforce component to Salesforce, then place the component on Account, Contact, Lead, Opportunity, and Case pages. It queries Zendesk in real time, stores no ticket data in Salesforce, and does not consume Salesforce API calls. The Case page version is view only; on the other four objects, Salesforce users can view, create, and edit tickets and add public or internal comments. Matching is configured in the Map fields section: by default an Account shows tickets whose requester organization name matches the account name, a Contact shows tickets whose requester email matches the contact email, Opportunities match on organization name, and Leads on requester email. Two requirements in the Salesforce connected app matter: Permitted Users set to admin approved users are pre-authorized, and Require Proof Key for Code Exchange (PKCE) enabled. Without PKCE only the admin who connected the integration can see tickets. The Lightning component also needs a My Domain subdomain, and matching criteria longer than 4,000 characters return no results.

Ticket sync is the option account teams usually want, because it puts a persistent record in Salesforce that reports and workflows can use. It runs one way, Zendesk to Salesforce, and Zendesk's setup guide has no path for case edits flowing back to tickets. The setup order: create a Salesforce case record type for Zendesk tickets, install the ticket sync package from Admin Center, configure the ticket-to-case mapping, and activate the trigger in Zendesk Support. The package adds standard Zendesk ticket fields to the Case object and maps them: Ticket Type to Case Type, Ticket Priority to Case Priority, Ticket Status to Case Status, Ticket Subject to Case Subject, Requester ID to ContactId, and Organization ID to AccountId. Type, priority, and status mappings can be customized; most of the others cannot. On first save, Zendesk creates a webhook and a trigger both named (Salesforce Integration) Sync tickets to Salesforce, and the trigger posts a small JSON body with the ticket ID and your Salesforce org ID. Custom ticket fields can be mapped to case fields, but multi-line, credit card, regex, lookup relationship, and multi-select field types are not supported and cause errors. Attachments do not sync, already-closed tickets do not sync, and if any required case field is unmapped the sync fails.

Data sync runs the other way, Salesforce to Zendesk, and it too is one way: changes made in Zendesk do not write back. Salesforce accounts create and update Zendesk organizations, and Salesforce contacts or leads create and update Zendesk users. Accounts match on account name by default, or on another unique account field you choose; contacts and leads match users by email. If the sync finds more than one matching record it cannot decide which one to update, so duplicate account names or shared emails on the Salesforce side become silent gaps on the Zendesk side. A sync fires when a mapped field is created or updated in Salesforce; edits to unmapped fields do nothing, and updates made indirectly through flows or Apex may not sync if the triggering user lacks edit rights. Field mapping supports standard and custom fields with type compatibility rules, and three fields append instead of overwrite: tags, email, and phone. Long, rich, and encrypted text areas, lookup fields, record type IDs, and formula fields cannot be mapped. You can add filters with up to three ALL conditions and three ANY conditions, and values are case sensitive. Prerequisites in Salesforce are API access, Streaming API enabled, and PushTopic read permission, because the sync consumes Salesforce streaming API limits. For security, a contact will never sync onto a Zendesk user who is an agent or admin, and person accounts arrive as organizations rather than users.

The fourth component is the Salesforce app for Zendesk Support, turned on from the Support app tab in the integration settings. It shows Salesforce data in the ticket sidebar when an agent opens the Apps panel on an existing ticket. Admins pick which Salesforce objects to display and which Zendesk field must exactly match which Salesforce field to find the record; numeric fields cannot be used for matching, and neither can custom user or organization fields. Zendesk recommends showing at most five fields per object to keep the sidebar fast. Data is cached for 60 minutes by default, adjustable in either direction as a trade between freshness and Salesforce API consumption, and admins can allow agents to refresh manually. This app is read-only from the agent's side: it displays Salesforce records but does not create or update them from Zendesk. It does not follow Salesforce account hierarchy, and it supports connections to multiple Salesforce orgs.

The native integration is deliberately one way in each direction. If you need a true bidirectional sync, for example case status written back onto the ticket, or opportunities and custom objects kept in step with tickets, you move to a connector. Exalate's connector, listed on the Salesforce AppExchange with a 4.9 rating across 21 reviews at the time of writing, syncs Salesforce cases, tasks, accounts, opportunities, and products with Zendesk tickets in real time in both directions, uses a scripting engine for mapping rules, and starts at $8,000 per integration per year on the listing. Automation platforms such as Zapier cover lighter event-driven flows. The custom route is the Zendesk Tickets API: GET, POST, and PATCH on /api/v2/tickets, with a dedicated rate limit on the list endpoint of 100 requests per minute (300 with the High Volume API add-on), and an external_id property built for holding the ID of a linked record in another system such as a Salesforce case. Whichever route you pick, the sizing question is the same: how many tickets change per day, and does the Salesforce edition's API and streaming allowance cover that plus everything else already using it.

Support tickets are where customers state what they were promised and what they will escalate, which is why account managers and CSMs who own renewals want them in the CRM. Once tickets and cases exist in both systems, every mapped field needs a named owner. A workable default with the native integration: Salesforce owns account and contact identity, so data sync creates organizations and users and nobody edits those by hand in Zendesk; Zendesk owns ticket status, priority, and subject, so ticket sync writes those onto the case and Salesforce users treat them as read-only; and anything a Salesforce user wants to say to support goes through ticket view as a comment rather than a case field edit that would never make it back. Pick the matching key on purpose (email for people, a unique account field rather than the account name for companies) and clean duplicates before turning on sync, because the integration skips records it cannot match uniquely. Then decide the review step: which writes happen automatically, which get a human look, and where the integration log gets checked when the count of synced cases does not match the count of tickets.

Mindlyft (ASTRA) builds and runs cross-tool workflows like this one on subscription: the mapping, the ownership rules, the review step, and the monitoring, for $5,995 a month with the first workflow free. Details at mindlyft.in.