Why You Can't Reassign Those Accounts to a Queue (and What to Do Instead)

When someone leaves a nonprofit — a staff member, a volunteer admin, a contractor from a long-ago migration — they usually leave still owning thousands of records. The clean, durable fix for ownerless records is a Queue: a shared bucket that owns records instead of a person, so the next departure doesn’t recreate the problem.

I recommended exactly that to a client recently for a departing volunteer’s 3,200 application records, and it worked beautifully. Then we turned to the same volunteer’s Accounts and Contacts and hit a wall that surprises almost everyone:

Queues can only own Leads, Cases, and custom objects. Accounts and Contacts cannot be queue-owned. Ever.

It’s not a setting, not a permission, not an edition limit. When you create a queue, the “Supported Objects” list simply offers Lead, Case, and your custom objects. The core relationship objects — Accounts, Contacts, Opportunities* — must be owned by an active human user. (*Opportunities have their own wrinkle: also not queue-eligible.)

Why Salesforce draws the line there

Leads and Cases are work to be claimed — things that arrive, sit in a shared pool, and get picked up. Accounts and Contacts are relationships, and the platform’s sharing model, territory logic, and rollups all assume a relationship has a responsible person. Whether you agree or not, the behavior is foundational and isn’t changing.

The playbook that actually works

So a real departed-staff cleanup is a two-track move:

1. Queue-eligible records → a queue. Create it (Setup → Queues), add the relevant staff as members so a human can still grab a record, and bulk-reassign. For Leads, note that bulk reassignment doesn’t re-fire assignment rules by default (usually what you want), and converted Leads can’t be moved at all — they’ll throw CANNOT_UPDATE_CONVERTED_LEAD and simply stay put, which is harmless.

2. Accounts and Contacts → a named active user. Pick the person who actually inherits the relationships — a program director, the new coordinator. If no single person is right, pick the least wrong person and move on; an active not-quite-right owner beats an inactive one, because records owned by inactive users quietly degrade (automations error, updates fail, new related records misbehave).

3. Then deactivate the departed user. Order matters: Salesforce blocks deactivation while the user is referenced as a default owner anywhere (site guest default owner, default lead owner, workflow user), so repoint those references first, then reassign, then deactivate.

One more useful truth: deactivating someone does not technically require reassigning their records — ownership can sit with an inactive user indefinitely. Reassign for usability, not because the platform forces you. That distinction matters when you’re staring at 1,900 records wondering if tonight’s the night: you can deactivate today and do the reassignment mapping thoughtfully next week.

The five-minute check for your org

Run a report (or ask your admin to query) records grouped by Owner, and look for owners who are inactive users — especially on Accounts and Contacts. Most orgs that have ever had a migration, a contractor, or normal turnover find at least one ghost owner holding hundreds of relationships. Now you know both halves of the fix — and why the “just make a queue” advice you read for Leads won’t carry over.