Zendesk Domain Collision Between Organizations
The expected domain for a Salesforce account is already attached to a different Zendesk organization. Gremlin emits org_domain_attached_elsewhere and blocks the add_org_domain action with blocked_reason = domain_belongs_to_other_org. This is deliberate: Gremlin never steals a domain from another org.
Published April 17, 2026 - Part of the Zendesk drift audit guide
Short answer
Gremlin blocks this by design. Resolution is a human decision in Zendesk.
- org_domain_attached_elsewhere means the expected domain already belongs to another Zendesk org.
- add_org_domain is blocked with blocked_reason = domain_belongs_to_other_org. Gremlin never steals domains.
- Decide which org should own the domain using Salesforce account ownership, ticket volume, and user count as evidence.
- Detach the domain from the current owner in Zendesk admin, then re-run the audit.
- Dependent users may appear as user_missing_expected_membership or user_default_org_not_expected, both of which are safe-to-apply after the collision clears.
What org_domain_attached_elsewhere means
A domain is a shared resource in Zendesk. Two orgs cannot own the same normalized domain at once.
The failure mode
Salesforce account ACME003 expects the domain acme-biotech.com on its Zendesk org. The audit finds acme-biotech.com already attached to a different org 900012. Attaching it to the ACME003 org would either fail or reroute users and tickets from org 900012.
Why it is blocked
add_org_domain has a precheck: it never attaches a domain that already belongs to another Zendesk org. Blocking is not a bug. It is how Gremlin stays a safe apply surface. The collision needs a human to decide which org keeps the domain.
Trace the collision from the terminal
g-gremlin zendesk drift trace --sf-account-id 001ACME003
Salesforce account: 001ACME003 (Acme Biotech)
Expected domains: acme-biotech.com
Resolved Zendesk org: 900031 "Acme Biotech" external_id: 001ACME003
Current domains: acmebio.com
Missing domains: acme-biotech.com
Domain collision precheck:
acme-biotech.com is currently attached to Zendesk org 900012 "Acme Bio Holdings"
(external_id: 001HOLD007, users: 24, tickets 30d: 88)
Issue: org_domain_attached_elsewhere (critical, review-only)
Prepared actions: 0
Blocked actions: 1 (reason: domain_belongs_to_other_org)Resolution path
Trace the collision
Run g-gremlin zendesk drift trace --sf-account-id <id>. The trace names the domain, the org that currently holds it, and the org that expected it. fix_plan.csv also lists the blocked action with blocked_reason = domain_belongs_to_other_org.
Decide which org owns the domain
Common scenarios: acquisitions (domain should move to the parent org), subsidiaries (domain belongs to the subsidiary, not the parent), or a misconfigured historical org. Use Salesforce account ownership, ticket volumes, and user counts as evidence.
Detach the domain in Zendesk
In Zendesk admin, open the org that currently holds the domain and remove it. Do this only after deciding where the domain should live. If users on that domain should move with it, plan that move before detaching.
Re-run the audit
Run g-gremlin zendesk drift audit. The org_domain_attached_elsewhere issue should clear. If the target org is now correctly resolved, add_org_domain becomes safe-to-apply on the next run and will attach the domain to the right org.
Move dependent users if needed
If users were attached to the old org by domain, Gremlin may now emit user_missing_expected_membership or user_default_org_not_expected for those users. Those are safe-to-apply via assign_user_to_org and move_user_to_org.
FAQ
What is org_domain_attached_elsewhere?
Gremlin found an expected domain for one Salesforce account that is already attached to a different Zendesk organization. Adding the domain to the expected org would create a conflict, so the action is blocked with blocked_reason = domain_belongs_to_other_org.
Why does Gremlin block add_org_domain in this case?
Because stealing a domain from another org would reroute tickets, reassign users, and quietly corrupt the customer graph. The precheck against every other Zendesk org is a safety guarantee, not a limitation. Resolving the conflict is a human decision.
How do I find which Zendesk org currently holds the domain?
g-gremlin zendesk drift trace --sf-account-id <id> prints the conflicting org id, name, and domain set. org_issues.csv and fix_plan.csv also carry the evidence fields. Once you know which org holds it, you can make the ownership decision in Zendesk.
Does the CLI ever detach a domain automatically?
No. The 4 safe actions in v1 are set_org_external_id, add_org_domain (only when no collision precheck fires), assign_user_to_org, and move_user_to_org. Detaching a domain from an existing org is explicitly out of scope and stays manual.
What causes domain collisions between Zendesk organizations?
Mergers and acquisitions, subsidiaries that share a parent domain, historical Zendesk orgs created before the canonical contract was set, and manual edits by support teams. The audit catches all of these consistently.
What is the difference between org_domain_attached_elsewhere and org_missing_expected_domain?
org_missing_expected_domain is the safe case: an expected domain is not attached to any org, so add_org_domain can attach it to the expected org. org_domain_attached_elsewhere is the blocked case: the expected domain is already attached to a different org, so add_org_domain is not safe and Gremlin records blocked_reason = domain_belongs_to_other_org.
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 pageZendesk drift playbook
Operator execution log: Slack message, prompt, audit, review, dry-run, apply.
Open pageFix duplicate external_id in Zendesk
The other critical blocker: two orgs share the same external_id.
Open pageLink a Zendesk organization to a Salesforce account
The safe-to-apply path for org_missing_external_id.
Open pageFix wrong default organization in Zendesk
The safe-to-apply fix for user_default_org_not_expected.
Open pageAudit Zendesk and Salesforce sync from the CLI
The focused CLI walkthrough for the drift audit workflow.
Open pageKeep 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.
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.
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 calendarIf you want me to come in with context, leave your email and a short note before the call.