Salesforce User Onboarding and Offboarding, Automated

Salesforce user onboarding and offboarding automation is a half-solved problem, and almost every org has solved the wrong half. Salesforce shipped real tooling for granting access — User Access Policies will assign permission sets and group memberships the moment a user record is created. It shipped nothing for the expensive half: the twenty minutes of record surgery that has to happen the day someone leaves, which is still a checklist in a shared doc that somebody follows imperfectly at 4:45 on a Friday.

This is a build guide for closing that gap. Seven steps, the native tooling where native tooling is genuinely good, and the specific place where you stop configuring and start building.

The two halves of the job, and why only one got automated

Onboarding is a permission problem. A new rep needs a user record, a license, a role, a permission set group, queue memberships, a manager, a territory, and a dashboard. Every one of those is an assignment, and assignments are exactly the shape of thing a declarative tool handles well.

Offboarding is a record problem. The permissions are the easy part — you can strip those in a click. What takes the twenty minutes is everything that still points at that person: open opportunities, active cases, pending approvals, the lead queue they were assigned to, the four automations that name them as the default owner, the report subscriptions nobody remembers exist.

Salesforce automated the assignment half because assignments are uniform. It left the record half alone because the record half depends on your org — which objects matter, who inherits what, what “reassign” even means for a partially closed deal. That’s not a gap Salesforce can close for you. It’s a gap you close once, in your own org, and never think about again.

Step 1: Write the access matrix down as data, not as a doc

Before automating anything, the grant side needs a source of truth that a machine can read. Most orgs have one — it’s a spreadsheet tab called “who gets what,” and it’s three months stale.

Turn it into rows. One row per role-shaped thing you actually hire for: AE, SDR, CSM, Sales Manager, Support Tier 1, Ops. For each, list the permission set group, the queues, the public groups, the role, and the license type. Not the permission sets — the group. If you are still assigning nine individual permission sets per person, consolidate them into permission set groups first; everything downstream gets simpler, and the group is the unit the automation will actually reference.

This step feels like busywork and it is the step that makes the other six possible. A policy can only act on criteria that exist as data on the user record. If “which team someone is on” lives only in your head, nothing can key off it.

Step 2: Let User Access Policies carry the grant half

This is the native tool, and for what it does it is good. A User Access Policy automatically grants or revokes access when a user record is created or updated. Salesforce documents exactly five things it can manage:

• Permission sets
• Permission set groups
• Permission set licenses
• Package licenses
• Public groups and queues

You can trigger a policy on user creation only, user update only, or either. The stated limits are generous for this purpose: up to 3 filters for applicable users, up to 10 filters on standard and custom user fields of type Checkbox, Number, Picklist, or Text, and up to 20 actions per policy. It requires Enterprise or Unlimited and the “Manage User Access Policies” permission.

Build one policy per row of your Step 1 matrix. Key it off a single picklist field on the user record — call it Team_Role__c — and have the policy assign that role’s permission set group plus its queue and public group memberships. Now creating a user with Team_Role__c = SDR produces a fully permissioned SDR without anyone opening Setup twice.

Two things to know going in. Filter logic is AND-only — the conditions you add all have to be met, so you can’t express “SDR or BDR” in one policy. And policies don’t chain: one policy firing doesn’t trigger another.

Step 3: Where the policy stops — and what still needs hands

Read that list of five again and notice what isn’t on it. A User Access Policy does not set the user’s role, their manager, their territory, or any other field on the user record. It grants access; it doesn’t populate the person.

So onboarding splits cleanly into two pieces. The access piece is a policy. The identity piece — role hierarchy position, manager lookup, division, locale, forecast category, the custom fields your org added — is still a create-the-record step, and it’s the step where people fat-finger things.

The honest version of “automate onboarding” is therefore: a policy that handles access, plus something that creates the user record correctly from an upstream signal. That upstream signal is usually your HR system, occasionally a form, occasionally a row someone pastes in. Wiring it is a small integration — and it’s the first place in this guide where you need code rather than configuration. Hold that thought; Step 7 is where it lands.

Step 4: Offboarding is not “deactivate the user”

Here is the fact that surprises admins who haven’t done this at volume: you cannot delete a Salesforce user. Ever. Salesforce’s own admin guidance is direct about why — deletion would orphan records, so deactivation is the only exit, and “deactivation removes login access while preserving historical activity and records.”

Which means a deactivated user still owns everything they owned. The records don’t move. The queue memberships resolve to a dead account. And the deactivation itself will fail if that user is still referenced as any of these:

• Default lead owner
• Default case creator
• Automated case user
• Default workflow user
• Recipient of workflow email alerts
• A user in a custom hierarchy field
• Customer Portal Administrator

Plus: if they were an approver, they have to be removed from every approval process or have their approval responsibilities reassigned first.

That list is the actual offboarding checklist, and it is why the task takes twenty minutes instead of one click. Every item is a lookup someone has to go find.

Step 5: Freeze first, then work the list

The sequence matters, and most checklists get it backwards by trying to deactivate first and discovering the blockers one error message at a time.

Freeze the user immediately. Salesforce recommends this explicitly: freezing “will lock their credentials while you work on deactivating the user across your company’s implementation.” Freezing is instant, it’s reversible, and critically it does not free the license — so it buys you the security outcome (no login) without forcing the cleanup to happen in the same minute.

Then work the blocker list, then reassign records, then deactivate. That ordering also gives you a safety valve: if it turns out the departure was a transfer rather than an exit, or the record reassignment picked the wrong inheriting rep, unfreezing is one field and nothing has been destroyed. Deactivating first and unwinding later is a far worse afternoon.

Freeze is the security event; deactivate is the accounting event. Separating them is what turns a panicked scramble into a job that can run on its own schedule.

Step 6: Reassignment at real volume

Now the records. Salesforce ships Mass Transfer Records, and you should know its exact shape before you plan around it.

It supports four things: Accounts, Leads, Service Contracts, and custom objects. That’s the list. It moves a maximum of 250 records at a time. Transferring an account brings along contacts, attachments, notes, open activities, and open opportunities owned by the current owner — with options for closed opportunities and opportunities owned by others.

And one behavior worth reading twice: in some editions, transferring accounts removes all previous access granted by manual sharing, Apex managed sharing, or sharing rules.

So for a departing SDR with 180 leads, the native tool is fine. For a departing AE with four years of accounts, 900 open activities, and a tail of cases — an object the tool doesn’t cover at all — you are doing several passes through a wizard capped at 250, and you are doing it by hand, on the day you can least afford it. This is the same ceiling that makes bulk updates without a data loader painful, and it shows up here for the same reason: the tools were designed for occasional admin work, not for a recurring business process.

Step 7: The build that closes it — a Departure record and a job that works it

Here’s what to build, concretely enough to hand to someone.

A lightweight custom object — Offboarding__c. Fields: the departing user, the effective date, the inheriting user (or a lookup per record type: accounts to one person, cases to another), a status picklist, and a completion timestamp. One record per departure. This is the thing that turns an ad-hoc scramble into a process with a paper trail.

An automation that fires on create. It freezes the user, then walks the blocker list programmatically: checks every custom hierarchy field, every approval process, every default-owner setting, and writes what it found onto the Offboarding record. Anything it can reassign, it reassigns. Anything needing a human decision gets flagged — with the record name, not a generic error.

A batch job for the records. Ownership reassignment in batch, scoped by object and by the inheritance rules on the Offboarding record, with no 250-record ceiling and no wizard. If your org routes new work through round-robin lead assignment, the departing user comes out of that rotation in the same transaction, which is the step most checklists forget until leads start disappearing into a dead queue.

A verification step. Re-query for anything still owned by or referencing the user. If it comes back empty, deactivate and stamp the Offboarding record complete. If not, the record stays open with a list.

That’s a day of work for someone who can write Apex, and it permanently converts a twenty-minute manual task with a long tail of misses into a form submission. The same object also gives you the onboarding side: an Onboarding__c record creates the user with the right identity fields, sets Team_Role__c, and lets the Step 2 policy do the rest.

The reason most orgs never build it

Nothing above is hard. A batch class, a custom object, a trigger, a few queries. Any Salesforce developer would scope it in an afternoon.

It doesn’t get built because it’s a small build, and small builds lose. They lose the prioritization meeting to revenue-facing work, they lose to the integration that’s already late, and they lose to the reasonable-sounding argument that the checklist works fine. The checklist does not work fine — it works until the week someone leaves while the admin is on vacation — but the failure is quiet and diffuse, so it never wins a sprint. This is the exact pattern behind most of the CRM tasks nobody should still be paying a developer for, and it’s item nine on our list of Salesforce problems worth fixing.

What changes the math is making the build cheap enough that it doesn’t need to win a sprint. That’s what Sentinel is for: you describe the Offboarding object and the batch job to your AI in plain language, and it builds and deploys them against your org — sandbox-first, with tests, with every change logged and a snapshot taken before the deploy, so a bad idea is a revert rather than an incident. If you want the setup path first, start with connecting Claude to your Salesforce org, then read what it means for your AI to be your CRM developer.

The decision rule

Use User Access Policies for the grant half — it’s the right tool and it’s already in your org. Freeze before you deactivate, always. Use Mass Transfer for small, account-and-lead-shaped departures and don’t pretend it scales past that.

And then decide whether “someone leaves” is a process in your business or an emergency. If people join and leave more than a few times a year, it’s a process, and processes deserve a build instead of a doc.

---

Got a small Salesforce build that keeps losing the prioritization meeting? That’s exactly the kind of thing worth handing to an AI that can actually deploy. Pricing is flat per Sentinel and is covered on a short demo call.

Book a Demo Call

Sources: Salesforce Help, Automatically Grant or Revoke Access with a User Access Policy and Mass Transfer Records; Salesforce Admins, Users May Come and Go, But Their Records Must Live On. ORG Endgame is not affiliated with Salesforce.