GuideZendeskDriftReview-only

How to Fix Duplicate external_id in Zendesk

Two or more Zendesk organizations share the same external_id for one Salesforce account. Gremlin emits org_duplicate_external_id and keeps every downstream safe action blocked until the duplicate is resolved in Zendesk. Here is why, and the exact resolution path.

Published April 17, 2026 - Part of the Zendesk drift audit guide

Read the pillar integration guide See the drift playbook

Short answer

This is deliberately review-only. Gremlin will not auto-resolve it.

org_duplicate_external_id means two or more Zendesk orgs share the same external_id for one Salesforce account.
Gremlin blocks every downstream safe action for that account because identity is ambiguous.
Fix it in Zendesk admin: pick the surviving org, clear or reassign external_id on the duplicates, merge users or tickets manually if needed.
Re-run g-gremlin zendesk drift audit. Dependent user and ticket blockers should clear.
Audit on a schedule to catch it next time before the graph gets worse.

What org_duplicate_external_id means

In a healthy Salesforce and Zendesk integration, Zendesk org external_id equals the Salesforce account id and is globally unique. Duplicates break that invariant.

The failure mode

Two Zendesk orgs both carry external_id = 001ACME002. When Gremlin tries to resolve the Salesforce account, both orgs match. There is no deterministic way to pick the correct one, so the account is flagged ambiguous and every dependent decision becomes review-only.

Why it is review-only

Picking the wrong surviving org would quietly corrupt the customer graph. Gremlin needs a human with Zendesk context to decide which org keeps the external_id, which gets cleared, and whether tickets or users need to move before the duplicate is retired.

Find the duplicate from the terminal

trace prints the full evidence chain: which orgs share the id, their names, domains, memberships, and ticket volumes.

g-gremlin zendesk drift trace --sf-account-id 001ACME002

Salesforce account: 001ACME002 (Acme Labs)
  Expected Zendesk org external_id: 001ACME002

Zendesk orgs with external_id = 001ACME002:
  - org 900001  "Acme Labs"         (domains: acmelabs.com)   users: 18   tickets(30d): 42
  - org 900047  "Acme Labs (Old)"   (domains: acmelabs.io)    users: 3    tickets(30d): 1

Issue: org_duplicate_external_id (critical, review-only)
  Downstream: user_resolution_blocked_duplicate_external_id (1)
              ticket_resolution_blocked_duplicate_external_id (1)
  Prepared actions: 0
  Blocked actions:  2  (reason: duplicate_external_id)

How to resolve org_duplicate_external_id

A five-step manual resolution in Zendesk, then a CLI re-audit to prove the drift count dropped.

Trace the ambiguous account

Run g-gremlin zendesk drift trace --sf-account-id <id> to see exactly which Zendesk orgs share the same external_id, their names, domains, and ticket volumes.

Pick the surviving Zendesk org

Usually the org with the most historical tickets, the most members, and the domain closest to the Salesforce account is the right survivor. Do not guess - look at the trace evidence.

Clear or reassign external_id on the duplicates

In Zendesk admin, open the non-surviving org and either blank its external_id or reassign it to the correct Salesforce account id. This is a manual action, not a CLI action.

Consider merging users and tickets manually

If the duplicate org has users or tickets that should belong to the survivor, move them in Zendesk before deactivating or deleting the duplicate. Gremlin does not merge orgs.

Re-run the audit

Run g-gremlin zendesk drift audit. The account should no longer appear with org_duplicate_external_id, and downstream user and ticket issues that depended on it should unblock.

FAQ

What is org_duplicate_external_id in Gremlin?

It is the issue code emitted when two or more Zendesk organizations share the same external_id value. In a healthy Salesforce and Zendesk integration, external_id is the canonical link: exactly one Zendesk org per Salesforce account. Duplicates make account resolution ambiguous, so Gremlin treats every downstream user and ticket decision for that account as review-only until the duplicate is resolved.

Why does Gremlin block automatic fixes for duplicate external_id?

Because picking the wrong surviving org would quietly corrupt the customer graph. Gremlin cannot deterministically decide which duplicate is the real org. It needs a human with Zendesk context to pick the survivor, clean up the other, and only then let the audit continue. This is why the issue is in the review-only list, not the safe-to-apply list.

How do I find which Zendesk orgs share an external_id?

Run g-gremlin zendesk drift trace --sf-account-id <id> (or --zendesk-org-id). The trace output shows every Zendesk org mapped to that Salesforce account, their names, domains, user counts, and why the account is blocked. org_duplicate_external_id rows also appear in org_issues.csv and all_exceptions.csv with full evidence.

Can the CLI merge Zendesk organizations automatically?

No. Gremlin explicitly does not create, merge, or delete Zendesk organizations in v1. The 4 safe actions are set_org_external_id, add_org_domain, assign_user_to_org, and move_user_to_org. Anything beyond that is review-only and resolved manually in Zendesk.

What does duplicate external_id break downstream?

Every user and ticket decision for the affected Salesforce account inherits the ambiguity. user_resolution_blocked_duplicate_external_id and ticket_resolution_blocked_duplicate_external_id are emitted for the dependent issues. Until you resolve the duplicate at the org level, Gremlin will not prepare safe actions for any user or ticket tied to that account.

How do I prevent duplicate external_id from happening again?

Audit on a schedule (weekly or in CI). Document which automation or person is allowed to write external_id on Zendesk orgs. Never let two systems independently create Zendesk orgs for the same customer without a pre-check against existing external_ids. Run g-gremlin zendesk drift audit after any bulk import.

Related Zendesk drift pages

Salesforce and Zendesk integration pillar

The audit-first integration contract: 12 issue codes, 4 safe actions, plan-hash-protected apply.

Open page

Zendesk drift playbook

Operator execution log: Slack message, prompt, audit, review, dry-run, apply.

Open page

Link a Zendesk organization to a Salesforce account

The companion safe-to-apply path for org_missing_external_id.

Open page

Zendesk domain collision between organizations

The other common blocker: domain_belongs_to_other_org.

Open page

Fix wrong default organization in Zendesk

The safe-to-apply user fix for user_default_org_not_expected.

Open page

Audit Zendesk and Salesforce sync from the CLI

The focused CLI walkthrough for the drift audit workflow.

Open page

Keep the conversation going

These pages are meant to help operators solve real problems. If you want the next guide, grab the low-friction option. If you need the implementation, not just the guide, book time.

Stay in the loop

Get the next guide when it ships

I publish architecture guides grounded in real implementations. No generic AI filler.

Use your work email so I can keep the list useful and relevant.

Book Mike directly

Need the implementation, not just the guide?

Book a 15-minute working session with Mike right on his calendar. Tooling, consulting, or a mix of both is fine.

Open Mike's calendar

If you want me to come in with context, leave your email and a short note before the call.

I'll route new requests into the internal website inquiries inbox so I can follow up fast.