failed to deactivate user user still owns records Salesforce

Not specified by the original author.

TL;DR

Salesforce blocks deactivation while the user owns records. Transfer ownership to an active user first, using the deactivate flow's transfer option or mass transfer, then deactivate. The license frees when deactivation completes.

"failed to deactivate user" user still owns records Salesforce

Use this when

• Deactivating a user fails citing owned records.
• Offboarding is stuck on the Salesforce step.
• The error lists records or objects still owned.

Not for this skill when

• Deactivation fails for another reason. Read the actual error.
• The goal is only to remove the license. Deactivation frees it, but check the license type rules.
• The user must keep access. Then do not deactivate at all.

Steps

1. Note the owned records or objects named in the error. Verify: you know the scope of the transfer.
2. Use Setup, then Users, then deactivate, choosing the transfer target user, or run mass transfer first for large sets. Verify: the transfer target is active and appropriate.
3. Confirm the transfer completes. Verify: the departing user owns nothing.
4. Deactivate the user. Verify: status is inactive.
5. Confirm the license is freed in Company Information. Verify: the seat is reclaimed.

Variant phrasings

cannot deactivate Salesforce user

The plain-English search.

transfer records before deactivate

The action-first phrasing.

user owns records error

The cause-first phrasing.

Compatibility: Salesforce user deactivation, all editions.

Why it happens

Record ownership is a hard dependency in Salesforce. The platform will not orphan records, so deactivation is gated on transferring them away first.

Edge cases / pitfalls

• The user owning records in objects the transfer tool skips; check queues, dashboards, and reports.
• Integration users owning records: transferring to a human may break the integration's expectations.
• The transfer target lacking access to the records being transferred.
• Large transfers timing out; run them in batches.

Provenance

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

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

Thread query: "failed to deactivate user" user still owns records Salesforce

TL;DR: Salesforce blocks deactivation while the user owns records. Transfer ownership to an active user first, using the deactivate flow's transfer option or mass transfer, then deactivate. The license frees when deactivation completes.

Not specified by the original author.

TL;DR

Freeze the user first, then deactivate and remove the license. A user that still owns records or has an active session resists deactivation and keeps consuming the seat.

Error

Salesforce user deactivation failed: license still counted for the user

Steps

1. Freeze the user to block access immediately while you work. Expected: the user cannot log in.
2. Transfer ownership of the user's records (accounts, opportunities, and anything else they own) to an active user or a queue. Expected: the user owns nothing.
3. Deactivate the user and remove the Salesforce license from their record. Expected: the license returns to the pool.
4. Verify the license count dropped in Company Information. Expected: the seat reclaimed.

When to use

• Deactivation fails or the license count does not drop
• Offboarded users still show as consuming licenses
• The user owns records that block deactivation

When not to use

• The license type is a permission-set license (a different limit)
• You want to keep the user read-only (use freeze without deactivation)
• The count is wrong for active users (an assignment problem)

Tool compatibility

Salesforce Setup user management, all editions with user licenses.

Variant phrasings

deactivation blocked by the user owning records

Transfer ownership first; Salesforce will not deactivate an owner.

license still counted after successful deactivation

Check for a second license type on the user (e.g. a permission set license).

Why it happens

Salesforce ties license consumption to the user record, and deactivation has prerequisites (no owned records, no active sessions in some flows). Skipping the prerequisites leaves the seat consumed.

Provenance

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

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

Thread query: "Salesforce user deactivation failed" license still counted

TL;DR: Freeze the user first, then deactivate and remove the license. A user that still owns records or has an active session resists deactivation and keeps consuming the seat.

Not specified by the original author.

TL;DR

Box will not delete a user who still owns content. Transfer ownership to a manager or a service account first using the delete flow's transfer option, then delete the user. The license frees on deletion.

"Box user deletion failed" content ownership transfer required

Use this when

• Deleting a Box user fails citing content ownership.
• Offboarding stalls on the Box step.
• The user owns files in shared folders.

Not for this skill when

• The user owns nothing. Then deletion should work; look for another cause.
• The goal is only to remove access. Deactivate instead of deleting.
• Content must be preserved under legal hold. Transfer to the hold custodian, not a manager.

Steps

1. Open the user in the Box admin console. Verify: you see their owned content summary.
2. Start the delete flow and choose the transfer-content option, picking the recipient. Verify: the recipient is active and appropriate.
3. Confirm the transfer completes; large accounts take time. Verify: ownership moved.
4. Delete the user. Verify: the account is gone.
5. Confirm the license count drops. Verify: the seat is reclaimed.

Variant phrasings

Box delete user content

The action-first phrasing.

transfer ownership Box

The step-first search.

cannot delete Box user

The plain-English phrasing.

Compatibility: Box admin console user management, all business plans.

Why it happens

Box protects content from being orphaned. Ownership transfer is the prerequisite gate, and the delete API enforces it rather than deleting content with the user.

Edge cases / pitfalls

• Content in shared folders with complex permissions: verify the recipient gets usable access, not just ownership.
• Transfers over the API timing out on huge accounts; the console flow handles large transfers better.
• The recipient leaving later with the transferred content still under their name; use a service account for durability.
• Legal-hold content needing the hold custodian as recipient.

Provenance

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

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

Thread query: "Box user deletion failed" content ownership transfer required

TL;DR: Box will not delete a user who still owns content. Transfer ownership to a manager or a service account first using the delete flow's transfer option, then delete the user. The license frees on deletion.