What Happens to a Salesforce Account When Someone Leaves, Before It Becomes an Incident
- Architect
- 8 hours ago
- 2 min read
Admins swap the same offboarding story often enough that it's basically a genre: an account gets deactivated, everyone moves on, and weeks later someone finds a permission set assignment that never got revoked, or a batch of records still sitting under a name nobody can reach anymore. Deactivating a user stops their login. It doesn't touch what they owned, and it doesn't clean up what was granted to them on a timer.
That gap is where offboarding actually goes wrong — not the day someone leaves, but the loose ends nobody checked before deactivation.
What did they own?
Deactivating a user freezes their records in place — every account, opportunity, and custom-object row still shows them as owner, just now unreachable by the person who used to manage it. Finding the full list natively means a SOQL query per object, run against every object in the org that has an owner field, hoping none got missed.
Data Reassignment Assistant, part of Power User Toolkit, automates the tedious part: pick the user, and it generates the full list of objects in the org that are queryable, updateable, and have an OwnerId field, then counts what they own across all of them in parallel, exportable to CSV. It's an audit, not a bulk-reassignment button — it tells you the scope so reassignment happens as a deliberate decision, not a guess about what got missed.
What access did they still have that hasn't expired yet?
Deactivation doesn't touch permission set assignments with an expiration date already set — those just run out on their own schedule, whether or not the person is still at the company. If someone had temporary elevated access from a project that wrapped up around the same time they left, it can outlive their last day by weeks.
Expiring Permission Sets Assignments lists every assignment with an expiration date inside a chosen window across the whole org, soonest first, with a direct link into Setup to revoke it early instead of waiting for it to lapse on its own.
The pattern that actually causes incidents
It's rarely the obvious ownership that causes a problem — everyone remembers to reassign the accounts a departing sales rep owned. It's the custom object nobody flagged, or the assignment tied to a project that ended around the same time the person did. Running both checks before deactivation, as a standing step rather than an afterthought, is what catches it before it becomes the story someone tells in a security postmortem instead of a Slack thread.
If sensitive data is also part of what they had access to, see How to Find PII Hiding in a Salesforce Org. For the full breakdown of each tool, see Before You Deactivate a Salesforce User, Find Out What They Own and The Permission Set Assignment About to Expire That No One Noticed. Or start at the Power User Toolkit overview.
Comments