Comment corriger CANT_DISABLE_LAST_ADMIN dans les déploiements Salesforce

Salesforce empêche de désactiver ou de geler le dernier utilisateur actif disposant d'un accès System Administrator, afin d'éviter de verrouiller l'org.

Survient pendant : un DML de gestion des utilisateurs à l'exécution, pas un déploiement de métadonnées

Ce que cela signifie

CANT_DISABLE_LAST_ADMIN se déclenche lorsqu'une opération tente de désactiver, geler ou retirer autrement l'accès administrateur du dernier utilisateur actif qui le détient. Salesforce impose cela comme garde-fou : une org sans administrateur actif ne peut pas être récupérée via l'interface, donc la plateforme refuse purement et simplement le changement plutôt que de le laisser se produire par accident.

Cela s'applique à tout utilisateur disposant de l'équivalent d'un accès System Administrator, pas seulement au profil littéralement nommé ainsi ; un profil personnalisé ou une combinaison de permission sets accordant "Modify All Data" plus "Manage Users" peut déclencher la même protection.

Diagnostic

Causes courantes

Le déprovisionnement en masse désactive des admins sans vérifier leur nombre

Un script d'offboarding désactive un lot d'utilisateurs, y compris des admins, sans vérifier combien d'admins actifs il en reste ensuite.

L'ancien admin est désactivé avant que le nouveau ne soit pleinement actif

Un processus de transfert désactive l'accès de l'admin sortant avant que le compte et les permissions de l'admin remplaçant soient confirmés actifs.

Des changements de permission sets suppriment un accès admin-équivalent à l'échelle de l'org

Un déploiement met à jour des affectations de permission sets de façon à retirer "Modify All Data" à tous les utilisateurs actifs restants en même temps.

La solution

Confirmez qu'un autre admin actif existe avant d'en désactiver un
Vérifiez le nombre d'utilisateurs actifs disposant d'un accès System Administrator ou équivalent avant l'exécution de toute étape de déprovisionnement.
```
SELECT COUNT(Id) FROM User
WHERE IsActive = true AND Profile.PermissionsModifyAllData = true
```
Activez d'abord l'admin remplaçant
Séquencez l'offboarding pour que le compte et les permissions du nouvel admin soient confirmés fonctionnels avant de désactiver l'ancien.
Ajoutez une vérification du nombre d'admins aux scripts de pré-déploiement ou pré-déprovisionnement
Intégrez un garde-fou directement dans l'automatisation pour qu'elle ne puisse pas soumettre un changement qui laisserait zéro admin actif.

En pratique

Comment Serpent évite cela

L'accès aux org dans Serpent est lié à l'historique des tâches et des déploiements, si bien qu'un script de déprovisionnement qui laisserait une org sans administrateur actif échoue clairement au lieu de verrouiller silencieusement un sandbox ou un scratch org. Voir la bibliothèque des erreurs de déploiement Salesforce.

Traçabilité des approbations et des audits dans Serpent

Prévention

Conservez en permanence au moins deux admins actifs par org

Considérez une org à admin unique comme un incident en attente ; un second compte admin actif est l'assurance la moins coûteuse contre cette erreur et contre le verrouillage en général.

Automatisez l'offboarding en étapes ordonnées, pas en un seul lot

Séparez "accorder le nouvel admin" et "révoquer l'ancien admin" en étapes distinctes et séquentielles avec une vérification entre les deux.

Vérifiez les déploiements de permission sets pour des changements d'accès à l'échelle de l'org

Signalez tout déploiement touchant Modify All Data ou Manage Users pour plusieurs utilisateurs à la fois pour une revue manuelle avant son exécution.

Erreurs associées

INSUFFICIENT_ACCESSLe problème inverse : un utilisateur ou un compte de service avec trop peu d'accès au lieu d'un accès excessif qu'on retire.INSUFFICIENT_ACCESS_OR_READONLYUne erreur de permissions apparentée lorsque l'accès d'un utilisateur de déploiement ou d'intégration est défini de façon trop restreinte.

Questions fréquentes

CANT_DISABLE_LAST_ADMIN, expliqué

Cela bloque-t-il aussi le gel du compte d'un admin, pas seulement sa désactivation ?

Oui. La même protection s'applique au gel du dernier admin actif, puisqu'un utilisateur gelé ne peut pas non plus se connecter.

Le profil utilisé par l'admin compte-t-il, ou seulement le niveau de permission ?

C'est le niveau de permission qui compte. Tout utilisateur actif dont le profil ou les permission sets accordent un accès admin-équivalent, notamment Modify All Data, compte pour le minimum, quel que soit le nom du profil.

Que faire si je dois vraiment retirer le seul admin, par exemple pour décommissionner une org ?

Désactivez d'abord tous les autres utilisateurs et laissez l'admin actif en dernier, ou contactez le support Salesforce si l'org elle-même est entièrement décommissionnée.

Démarrez gratuitement. Sans carte bancaire, sans installation, sans engagement.

Configuration en moins de 15 minutes. Aucun recrutement DevOps nécessaire.

Démarrer gratuitement Réservez une démo