How to Keep Zendesk and Salesforce from Drifting Apart
Zendesk-Salesforce drift is when Salesforce and Zendesk no longer agree on customer identity for an org, user, or ticket. The useful first answer is an audit artifact: orphan orgs, domain mismatches, corrupted fields, safe fixes, blocked fixes, and a plan hash that gates live changes.
Published April 10, 2026 - Updated April 28, 2026
What buyers recognize in the first screen
Reserved .example domains below are fictional and not customer data.
ORPHAN ORGS
7Northshore Medical Network
Zendesk org exists, Salesforce account key is missing.
Bay Valley Health System
Legacy support-created org has no canonical external_id.
Westside Hospital Group
Duplicate org survived a cleanup and no longer maps cleanly.
DOMAIN MISMATCHES
9Northshore Medical Network
have northshoremed.health.example / missing northshoremed.example
Bay Valley Health System
have bvhs.bayvalley.example / missing bvhs.example
Westside Hospital Group
have westsidehospital.westernu.example / missing westsidehospital.example
Anonymized healthcare customer
A healthcare RevOps team flagged one wrong Zendesk-Salesforce link. Our audit found 17 more like it they did not know about, plus a separate Salesforce data corruption bug: URL slugs in the domain field. Total time: 30 minutes.
30-second answer
Definition first, then the practical operator move.
Zendesk-Salesforce drift means the support system and CRM disagree about customer identity. Audit first: compare Salesforce accounts against Zendesk orgs, users, memberships, and tickets; group exceptions by account; dry-run fixes; and require a matching plan hash before any Zendesk-side apply.
Here's what an audit finds
The useful output is not a dashboard. It is a small set of files an operator can inspect, filter, send to support ops, and rerun after fixes.
Total issues
Orphan orgs
Domain mismatches
Corrupted fields
Safe actions prepared
Blocked actions
Concrete artifact set
The files that turn drift into work your team can triage.
summary.md
The 30-second readout: total issues, blocked actions, prepared actions, and next step.
exceptions_by_account.csv
The operator queue grouped by Salesforce account, with issue codes and blockers.
fix_plan.csv
A reviewable table of prepared Zendesk-side actions and blocked rows.
fix_plan.json
The canonical plan payload with source paths, action payloads, and plan_hash.
apply_receipt.json
The dry-run or live receipt with attempted, applied, skipped, and blocked action results.
exceptions_by_account.csv preview
Fictional rows, real shape: one customer account, grouped evidence, clear next action.
| account | issues | prepared | blocked | top evidence |
|---|---|---|---|---|
| Northshore Medical Network | 5 | 2 | 1 | domain_missing, slug_in_domain_field |
| Bay Valley Health System | 3 | 1 | 2 | org_duplicate_external_id |
| Westside Hospital Group | 4 | 3 | 0 | org_missing_expected_domain |
Sample plan_hash: 9f110f9c01f07b87301797c54a693780ab97b4d097142ade130152e5fe5a5f6e
How to read the output
Do not start by fixing rows. Start by separating identity gaps, domain evidence, and source-data corruption so the right owner sees the right problem.
Orphan orgs
A Zendesk organization has no matching Salesforce account key, or Salesforce has an account that should have a Zendesk org and does not. These rows tell support ops where customer identity has split.
Evidence cue
Look for account_missing_zendesk_org, org_missing_external_id, or no resolved target org.
Domain mismatches
The org exists, but the domain attached in Zendesk disagrees with the approved domain in Salesforce. This is where shared systems, clinics, affiliates, and parent domains create wrong customer attachment.
Evidence cue
Read have/missing pairs before changing domain_names. Shared-domain rows should stay blocked.
Corrupted fields
The audit can expose source-data bugs that were not part of the original complaint, such as URL slugs stored in a Salesforce domain field instead of domains.
Evidence cue
Rows like /accounts/northshore-medical-network are data bugs, not Zendesk mapping bugs.
How to apply fixes safely
The apply path is intentionally boring: dry-run first, review the receipt, then require the same plan hash for live Zendesk-side changes.
Run apply without --apply first
Dry-run revalidates the plan against current Zendesk state and writes apply_receipt.json without mutating Zendesk.
Review the receipt and blockers
Prepared rows can still skip if preconditions changed. Blocked rows need an operator decision before a new plan is generated.
Gate live apply with plan_hash
Live apply requires --apply and --confirm-plan-hash matching fix_plan.json so a stale or edited plan cannot run by accident.
Cap the blast radius
Use --max-actions and --max-per-account for staged rollout. Salesforce remains a reference input, and ticket issues remain detection rows.
Operating model
The framework still matters. It just belongs after the audit artifact, because the artifact is what makes the problem legible.
Salesforce owns customer identity
Account ownership, lifecycle state, reporting, and the canonical external key stay authoritative in Salesforce.
Zendesk stores the stable key
Zendesk organization external_id stores the Salesforce account key. Org name remains display text, not the identity anchor.
Resolution order is explicit
Stored Zendesk org ID wins first, external_id wins second, normalized domain wins third, and ambiguous rows stay review-first.
Reconciliation is scheduled
Compare accounts, orgs, memberships, and ticket attribution weekly or nightly so the queue stays small.
Exceptions are grouped
Duplicate external IDs, shared-domain collisions, missing orgs, and membership mismatches become account-level review rows.
Run your first Zendesk drift audit with Mike
Two steps, no procurement cycle, no formal pilot. Download the Gremlin CLI free trial, then book a working session. Mike will help you point Gremlin at your Zendesk and Salesforce credentials, run the audit on your real data, and walk through the findings together.
You leave the session with a real fix list, not a sales pitch. The artifact shape is the one above: orphan orgs, domain mismatches, corrupted fields, and prepared Zendesk-side actions you can apply with the dry-run gate.
The session is a real working session, not a demo or a pitch. Bring your Salesforce alias and a Zendesk admin who can grant a read-only token.
FAQ
What is Zendesk-Salesforce drift?
Zendesk-Salesforce drift is when the two systems disagree about which customer owns an org, user, or ticket.
What should I audit first?
Start with org identity: external_id, expected domains, duplicate orgs, and orphan orgs. User and ticket issues are easier to read after org identity is clean.
Are domain mismatches safe to auto-fix?
Some are. A unique missing domain can be prepared for add_org_domain. Shared domains, conflicting orgs, and ambiguous healthcare affiliates should stay blocked for review.
Why does the plan hash matter?
The plan hash proves the live apply is using the reviewed fix_plan.json. If the plan changes, the hash changes and the apply gate refuses to run.
Does the audit write to Salesforce?
No. Salesforce is the reference input for this workflow. The prepared fixes are narrow Zendesk-side actions, and ticket issues are reported as detection rows.
Can I preview the workflow without credentials?
Yes. The demo flow runs init, audit, trace, and dry-run apply against bundled fixtures so your team can inspect the artifact shape first.
Power-user copy-paste
Four real `g-gremlin zendesk drift` commands from the documented demo flow.
g-gremlin zendesk drift init \
--config ./gremlin.zendesk_drift.demo.yaml \
--demo
g-gremlin zendesk drift audit \
--config ./gremlin.zendesk_drift.demo.yaml \
--ticket-lookback-days 3650 \
--run-id demo_walkthrough_audit
g-gremlin zendesk drift trace \
--config ./gremlin.zendesk_drift.demo.yaml \
--sf-account-id 001ACME
g-gremlin zendesk drift apply \
--plan ./artifacts/zendesk_drift/demo_walkthrough_audit/fix_plan.json