How to fix CANT_DISABLE_LAST_ADMIN in Salesforce deployments

Salesforce blocks deactivating or freezing the last active user with System Administrator access, to prevent locking the org.

Surfaces during: runtime user-management DML, not a metadata deploy

What it means

CANT_DISABLE_LAST_ADMIN fires when an operation tries to deactivate, freeze, or otherwise remove admin-level access from the last remaining active user who has it. Salesforce enforces this as a safeguard: an org with zero active admins can't be recovered through the UI, so the platform refuses the change outright rather than letting it happen by accident.

It applies to any user carrying the equivalent of System Administrator access, not just the profile literally named that, so a custom profile or permission set combination granting "Modify All Data" plus "Manage Users" can trigger the same protection.

Diagnosis

Common causes

Bulk deprovisioning deactivates admins without checking the count

An offboarding script deactivates a batch of users, including admins, without verifying how many active admins remain afterward.

Old admin is deactivated before the new one is fully active

A handoff process disables the outgoing admin's access before the replacement admin's account and permissions are confirmed active.

Permission set changes remove admin-equivalent access org-wide

A deployment updates permission set assignments in a way that strips "Modify All Data" from every remaining active user at once.

The fix

Confirm another active admin exists before deactivating one
Check the count of active users with System Administrator or equivalent access before any deprovisioning step runs.
```
SELECT COUNT(Id) FROM User
WHERE IsActive = true AND Profile.PermissionsModifyAllData = true
```
Activate the replacement admin first
Sequence offboarding so the new admin's account and permissions are confirmed working before the old one is disabled.
Add an admin-count check to pre-deploy or pre-deprovisioning scripts
Build a safeguard into the automation itself so it can't submit a change that would leave zero active admins.

In practice

How Serpent prevents this

Serpent's org access is tied to the task and deployment history, so a deprovisioning script that would leave an org without an active admin fails clearly instead of silently locking a sandbox or scratch org out. See the Salesforce deployment error library.

Approval and audit traceability in Serpent

Prevention

Keep at least two active admins in every org at all times

Treat a single-admin org as an incident-in-waiting; a second active admin account is the cheapest insurance against this error and against lockout generally.

Automate offboarding as ordered steps, not a single batch

Separate "grant new admin" and "revoke old admin" into distinct, sequential steps with a verification gate between them.

Review permission set deployments for org-wide access changes

Flag any deployment that touches Modify All Data or Manage Users across multiple users at once for manual review before it runs.

Common questions

CANT_DISABLE_LAST_ADMIN, answered

Does this also block freezing an admin's account, not just deactivating it?

Yes. The same protection applies to freezing the last active admin, since a frozen user also can't log in.

Does it matter which profile the admin uses, or just the permission level?

It's the permission level that matters. Any active user whose profile or permission sets grant admin-equivalent access, most notably Modify All Data, counts toward the minimum, regardless of the profile's name.

What if I genuinely need to remove the only admin, for example decommissioning an org?

Deactivate every other user first and leave the admin active until last, or contact Salesforce support if the org itself is being fully decommissioned.

Start free. No credit card, no install, no commitment.

Set up in under 15 minutes. No DevOps hire needed.

Start free Book a demo