The Phantom Tickets
RevOps MysteryCLI WorkflowA support ops manager pings Slack at 2pm: "Why don't this user's Zendesk tickets show up under their org?" The account exists. The domain is correct. The SFDC link is fine. Everything looks right — but tickets keep falling into a black hole. This is the story of how we diagnosed a systemic integration gap affecting 17 customer accounts and 172 users, built and deployed production Apex to fix it permanently, and verified everything with automated test coverage — all in one session.
Scope context: this is a Gremlin CLI workflow and the Zendesk coverage shown here is CLI-only in beta.
The Slack Message
Hey — I need you to look into this right now. [Support Ops Manager] is asking why Zendesk tickets from a user at one of our largest accounts don't get linked to the Zendesk Org. The org exists, the SFDC account is linked, the domain is set. I can't deal with what this guy is asking about but I need you to figure out what's going on and fix it asap. Please come up with a plan and fix it!
The Prompt
Forwarded the Slack message straight to Claude Code. Verbatim.
Hey — I need you to look into this right now. [Support Ops Manager] is asking why Zendesk tickets from a user at one of our largest accounts don't get linked to the Zendesk Org. The org exists, the SFDC account is linked, the domain is set. I can't deal with what this guy is asking about but I need you to figure out what's going on and fix it asap. Please come up with a plan and fix it!
Every RevOps Person Knows This Feeling
A simple Slack message that sounds like a 5-minute check. You start pulling the thread and it unravels into a massive project. The difference here: instead of spending your afternoon on it, you forward the message to Claude Code and it traces the user, finds the pattern, identifies the root cause, writes production code, deploys it, and remediates every affected account. You check Slack an hour later and there's a full write-up waiting.
How Claude Code Handles This
Verify
Confirm the SFDC Account, Zendesk Org, and domain config all look correct
Trace
Follow the specific user to find the broken link in the chain
Audit
Check the blast radius — is this one user or a pattern across the domain?
Root Cause
Identify the architectural gap: Zendesk only auto-assigns users at creation time
Build & Deploy
Write, test, and deploy production Apex to fix the gap permanently
Remediate
Backfill all 148 accounts across two waves, verify every assignment
"Support ops says tickets aren't linking to the Zendesk org. The account exists, the domain is correct, the SFDC link is fine. Let me verify the obvious first..."
"Org config is clean. If the org is fine, the problem is on the user side. Let me trace the specific user..."
"There it is. The user exists, the org exists, the domain matches — but the user simply isn't assigned. Diagnosis code: unassigned_user. Now the real question: is this just one user, or a pattern?"
"69% orphan rate. And the pattern is clear — users with older account IDs are unassigned, newer users are fine. This is a timing issue. Zendesk auto-assigns users to orgs by email domain, but only at creation time. If the user existed before the org was created, they never get assigned. The SFDC integration creates the orgs but has no step to go back and pick up pre-existing users."
"This isn't a one-account problem. It's systemic. The integration has a permanent architectural gap — Zendesk orgs get created from SFDC but pre-existing users never get assigned. This needs production Apex, not a config tweak."
"Building ZendeskUserAssignmentQueue — a queueable Apex job that searches Zendesk for users matching an org's email domains, validates server-side, and assigns them. Needs to handle pagination, multiple domains per org, and chain from the existing org creation job."
Writing ZendeskUserAssignmentQueue.cls
Writing ZendeskUserAssignmentQueueTest.cls
Modifying ZendeskOrgCreationQueue.cls — chaining user assignment after every successful org creation
Production deployment complete. Permanent fix is live — every new Zendesk org creation now auto-assigns pre-existing users.
The Gotcha
Zendesk's Search API does not support wildcards in the email: operator. A query like email:*@customer.edu silently returns zero results — no error, no warning. The first fix attempt completed successfully in 2 seconds, reported zero errors, and assigned nobody. The solution: plain-text domain search with server-side email validation. Every user returned by search gets checked with email.endsWith('@' + domain) before assignment. Baked into the Apex class so nobody hits this landmine again.
"Deployment handles future orgs. Now I need to backfill all existing accounts. Starting with the top 30 customer domains..."
Executed bulk fix via anonymous Apex — one ZendeskUserAssignmentQueue job per affected account. 13 jobs queued.
"Wave 1 clean. Expanding to all 148 SFDC accounts with Zendesk orgs..."
Wave 2: 116 more orphaned users across 20 additional domains. Prioritized 4 healthcare customers with highest impact.
All 45 users assigned and verified clean. Full remediation complete across all 148 accounts.
What Shipped
ZendeskUserAssignmentQueue
Apex · New
Retroactive user-to-org assignment via Zendesk API. Handles pagination, multi-domain orgs, and server-side email validation.
ZendeskUserAssignmentQueueTest
Apex · New
9 test methods with full mock callout coverage. Tests core flow, edge cases, API failures, and chained execution.
ZendeskOrgCreationQueue
Apex · Modified
Auto-chains user assignment after every new org creation. The permanent architectural fix.
The Diagnostic Toolkit
Three commands that turn a 30-minute manual investigation into a 60-second diagnosis.
Before & After
*One remaining edge case: a subsidiary using a different email domain not configured on the parent org.
The RevOps Win
A single Slack message turned into a full integration audit. What looked like one user's broken tickets was actually a systemic gap affecting 18% of support users across 17 customer accounts. Diagnosed with CLI tooling, fixed with production Apex (9/9 tests passing), backfilled across two waves covering all 148 accounts, and permanently prevented with an architectural fix to the org creation pipeline. The next time someone asks "why aren't these tickets linking?" — the answer is one command away.
Try This Workflow
Forward the next mystery Slack message to Claude Code. Let it pull the thread.