Your Salesforce Admin Left. Here's What Breaks First.

A few months after the only Salesforce admin leaves, I usually get a call that starts the same way: "Nothing is technically broken, but something feels off."

Over the past year I've stepped into several orgs right after a handover that never really happened. In one, a support inbox had quietly stopped turning emails into cases, so customers were writing in and nobody saw it. In another, a help desk integration stopped sending leads into Salesforce because it was connected through one person's login, and that login changed. In a third, a queue nobody owned had hundreds of requests sitting in "New," some of them more than a year old.

None of these teams were careless. They lost the one person who knew how everything was wired together, and Salesforce kept running on autopilot until it didn't.

Why this happens

Salesforce rarely fails loudly. Most of the work that matters runs in the background: flows, scheduled jobs, email-to-case, assignment rules and integrations. When one of those breaks, the warning goes to the admin. By default, Salesforce sends flow error emails to the user who last modified the flow. If that was your former admin, the alarms are going to an inbox nobody reads.

Three other things make it worse:

• Integrations tied to a person. If your help desk, marketing tool or billing system was connected using a named user's credentials, it can break the moment that user is deactivated, changes a password or loses a permission.
• Ownership by default. Default lead owner, default case owner, queue members, report and dashboard owners, the user automations run as. Salesforce often won't even let you deactivate someone until some of these are reassigned, which tells you how much hangs off one account.
• No record of the why. Every org has a field like Status_v2 and a flow called "Do Not Delete." Without the person who built them, nobody knows what's safe to touch.

The fix: a 30-day stabilization plan

You don't need to rebuild anything. You need to find out what's running, make sure someone hears about it when it fails, and stop depending on one login.

1. Freeze the account before you deactivate it. Freezing blocks login right away without changing anything assigned to that user. Secure the account first, untangle ownership second.
2. Reroute the alarms. In Setup, open Process Automation Settings and send flow and process error emails to your Apex exception email recipients instead of the last person who edited the flow. Then add a shared ops inbox to that recipient list so errors reach a team, not a person.
3. Inventory what runs on its own. List your active flows (sort by last modified), scheduled jobs, connected apps, email-to-case routing addresses, assignment rules and installed packages. Next to each one, write down who or what it runs as. This is usually a two to three hour exercise and it's the most valuable thing on this list.
4. Move integrations onto integration users. Enterprise and Unlimited editions include free Integration user licenses that are API-only. Reconnect each integration through a dedicated integration user so it no longer depends on anyone's login. Then test it end to end with a real record: send an email to the support address, create a test ticket, submit a web form, and confirm each one lands where it should. (I walk through this in more detail in stop connecting your integrations through one person's login.)
5. Audit the queues. Build a quick report of open cases, leads and tasks by owner and age. Anything owned by your former admin, or sitting untouched for more than 30 days, goes on a triage list. Pay special attention to records stuck in the very first status.
6. Write down the why. One short page per critical process: what triggers it, what it changes, and what to check if it stops. Setup Audit Trail keeps 180 days of configuration changes, which is a great way to reconstruct what your admin was working on before they left.
7. Decide who owns Salesforce next. A full-time hire, an outside partner, or someone who keeps things running while you hire. Be honest about the volume. Many teams find the backlog is bigger than they thought once steps 3 and 5 are done.

How to tell if this is you

• Your admin left in the last six months and there was no written handover
• You can't say who receives Salesforce error emails today
• At least one integration was set up by someone who isn't there anymore
• Reports have stopped matching what your team sees day to day
• There's a queue or list view nobody looks at
• Your sales or support team has started keeping side spreadsheets
• The admin search has been open for more than 60 days

If two or more of these sound familiar, your org is probably fine today and fragile tomorrow. The good news is that the first 30 days are mostly visibility work, and it pays off right away.

FAQ

What should I do first when my Salesforce admin leaves?

Freeze their user instead of deactivating it, send error emails to a shared inbox, and list everything that runs automatically and who it runs as.

What's the difference between freezing and deactivating a Salesforce user?

Freezing blocks login right away without changing anything assigned to the user. Deactivating can require reassigning default owners first and can break anything connected through that user.

Who gets Salesforce flow error emails?

By default, the user who last modified the flow. You can change this in Process Automation Settings so errors go to your Apex exception email recipients.

How can I see what my former Salesforce admin changed?

Setup Audit Trail keeps 180 days of configuration changes, which is usually enough to reconstruct recent work.

If you're in that gap right now, between one admin leaving and the next one starting, I'm always happy to talk it through. Some of my favorite engagements started as "keep the lights on while we hire."