Comment corriger MANAGER_NOT_DEFINED dans les déploiements Salesforce

Un processus d'approbation ou une automatisation dépendant de la hiérarchie échoue car le champ Manager de l'utilisateur n'est pas renseigné.

Survient pendant : la soumission d'une approbation à l'exécution, le plus souvent lors de l'exécution de tests Apex

Ce que cela signifie

MANAGER_NOT_DEFINED se déclenche lorsqu'une opération dépendant du rôle utilisateur ou de la hiérarchie de gestion, le plus souvent une étape de processus d'approbation configurée pour router vers le manager d'un utilisateur, atteint un enregistrement User sans valeur dans le champ Manager. Salesforce ne peut pas router l'approbation, ni terminer la logique dépendante de la hiérarchie qui l'a déclenchée, sans cette chaîne.

Les scratch orgs et les sandboxes fraîches créent systématiquement leur utilisateur admin par défaut sans Manager défini, ce qui explique précisément pourquoi cette erreur apparaît de façon disproportionnée dans les exécutions de tests CI plutôt que dans une org de production mature où la hiérarchie a été renseignée au fil du temps.

Diagnostic

Causes courantes

Des utilisateurs de test ou d'amorçage ont été créés sans manager
Des enregistrements User de fixture ont été insérés pour les tests sans renseigner le champ Manager dont le processus d'approbation a besoin.
Le champ Manager a été renseigné après que l'automatisation dépendante avait déjà tourné
Un script de migration a mis à jour le champ Manager d'un utilisateur à une étape ultérieure au processus qui en avait besoin lors de la configuration.
Le processus d'approbation atteint un utilisateur sans manager dans la chaîne
Une étape d'approbation "remonter la chaîne hiérarchique" atteint un utilisateur de premier niveau ou nouvellement créé dont le champ Manager est vide.

La solution

  1. Renseignez le champ Manager pour chaque utilisateur concerné
    Assurez-vous que les enregistrements User de test et d'amorçage utilisés dans les flux d'approbation ou dépendants de la hiérarchie ont un Manager assigné.
    User approver = new User(/* ... */);
    insert approver;
    User submitter = new User(ManagerId = approver.Id, /* ... */);
    insert submitter;
  2. Séquencez la configuration des utilisateurs avant l'automatisation dépendante de la hiérarchie
    Assignez les managers comme étape antérieure, avant qu'un processus d'approbation ou un déclencheur dépendant de la hiérarchie ne se déclenche.
  3. Ajoutez un approbateur de secours pour les utilisateurs en haut de la hiérarchie
    Configurez le processus d'approbation avec un approbateur par défaut afin que les utilisateurs sans manager soient tout de même routés quelque part.
En pratique

Comment Serpent évite cela

La configuration des tâches de Serpent peut préremplir les utilisateurs de test avec une hiérarchie complète, afin que les tests de processus d'approbation dépendant d'une chaîne de managers n'échouent pas pour une raison sans rapport avec le code testé. Voir la bibliothèque des erreurs de déploiement Salesforce.

Métadonnées et données dans un seul flux de déploiement dans Serpent

Prévention

Construisez une fabrique d'utilisateurs de test partagée qui définit toujours une chaîne de managers
Centralisez la création des User de test dans un utilitaire compatible @TestSetup qui assigne un manager par défaut, afin que chaque nouveau test hérite d'une hiérarchie valide.
Ajoutez des fonctionnalités de type Territory Management aux définitions de scratch org si nécessaire
Lorsque les processus d'approbation dépendent de la hiérarchie des rôles, amorcez au moins une hiérarchie d'utilisateurs à deux niveaux dans les scripts de configuration de scratch org, pas seulement l'utilisateur admin par défaut.
Configurez chaque étape d'approbation basée sur le manager avec un approbateur de secours
Traitez l'absence d'approbateur de secours comme une lacune de conception du processus d'approbation lui-même, pour intercepter les nouvelles recrues ou les utilisateurs de premier niveau avant qu'ils n'atteignent une impasse.
Questions fréquentes

MANAGER_NOT_DEFINED, expliqué

Chaque processus d'approbation a-t-il besoin d'une étape basée sur le manager pour rencontrer cette erreur ?
Seuls ceux explicitement configurés pour router selon le manager ou la hiérarchie de rôle du soumissionnaire ; les processus d'approbation avec des approbateurs fixes ou basés sur une file ne sont pas concernés.
Un utilisateur peut-il être son propre manager pour contourner cela ?
Salesforce empêche qu'un utilisateur soit défini comme son propre manager direct, ce n'est donc pas un contournement valide ; utilisez plutôt un véritable second utilisateur ou une configuration d'approbateur par défaut.
Cela s'applique-t-il aussi aux approbations basées sur Flow, en plus des Approval Processes classiques ?
Oui. Toute automatisation qui résout dynamiquement le "manager du soumissionnaire", qu'il s'agisse d'une étape d'Approval Process classique ou d'un Flow utilisant le motif de recherche Get Records/Manager, rencontre la même lacune sous-jacente lorsque le champ est vide.

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

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

Curieux de livrer plus vite avant de vous lancer ? Parlons-en

Sans engagement.