zendesk "user is suspended" error merging duplicate users

TL;DR

Zendesk refuses to merge a suspended user because merging is a write to both records and suspended records are locked. Un-suspend the account first, merge the suspended record into the active one, then re-suspend if the surviving record should stay suspended. Always merge into the record with the real ticket history so nothing gets orphaned.

The query

zendesk "user is suspended" error merging duplicate users

Use this when

• User merge fails with "user is suspended"
• Cleaning up duplicate user records
• A suspended spam account duplicates a real user
• You are scripting user merges

Not for

• Deciding whether to unsuspend a spammer
• Deleting end users (different flow)
• Merging organizations
• Ticket merge operations

Steps

1. Identify which record holds the real history

Before touching anything, check both users' tickets, organizations, and identity. The survivor should be the record with the genuine ticket history and the correct primary email. Merging into the wrong survivor orphans history.

Expected output: survivor record chosen based on ticket history.

2. Un-suspend the suspended record

Temporarily un-suspend so the merge can proceed. Note why it was suspended first: if it was spam, you want the merge to absorb it into the real user, not resurrect it.

Expected output: suspended record temporarily active.

3. Merge the duplicate into the survivor

Run the merge with the duplicate as the source and the survivor as the target. Verify the merge preview: tickets, identities, and organization membership move to the survivor.

Expected output: merge completes, duplicate record absorbed.

4. Re-apply suspension if the survivor should be suspended

If the surviving identity was the suspended one for a real reason (abuse, fraud), re-suspend after the merge. Do not leave a temporarily un-suspended abuse account active.

Expected output: correct suspension state on the survivor.

5. Verify tickets and identities landed correctly

Check the survivor's ticket list and email identities after the merge. Merges are hard to undo; verify immediately while the details are fresh.

Expected output: tickets and identities confirmed on the survivor.

Template: the merge runbook

Merging with a suspended user:
[ ] Survivor chosen: the record with real ticket history
[ ] Suspended record temporarily un-suspended (reason noted)
[ ] Merge run: duplicate into survivor, preview checked
[ ] Suspension re-applied if warranted
[ ] Survivor tickets and identities verified

Variant phrasings

zendesk merge suspended user

Steps 2 and 3. Un-suspend, then merge.

cannot merge duplicate users zendesk

Steps 1 and 5. Choose the survivor carefully, verify after.

zendesk user merge order

Step 3. Source into target, preview first.

Why it happens

Suspension locks the record against writes as an abuse control, and merging writes to both records. The API refuses rather than partially merging, which is the safe behavior. The un-suspend, merge, re-suspend sequence works because it respects the lock while letting an admin override it deliberately.

Edge cases

• Both records suspended: un-suspend both, merge, then set the final state once.
• Twitter or Facebook identities: social identities merge with their own rules. Check identity types before merging.
• The "duplicate" is actually two different people sharing an email: do not merge. Split the identities instead.
• API merges need admin permissions. An agent-level token gets a permissions error, not a suspension error.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst5LkaLf7OD4Wbt7qrmrzmA

Resolved from the public thread: https://vectle.com/posts/pst5LkaLf7OD4Wbt7qrmrzmA

Thread query: zendesk "user is suspended" error merging duplicate users

TL;DR: Zendesk refuses to merge a suspended user because merging is a write to both records and suspended records are locked. Un-suspend the account first, merge the suspended record into the active one, then re-suspend if the surviving record should stay suspended. Always merge into the record with the real ticket history so nothing gets orphaned.