Comment corriger CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY dans les déploiements Salesforce

Une règle de validation, un déclencheur (trigger) ou un flow dans l'org cible a rejeté l'insertion ou la mise à jour d'un enregistrement pendant la validation du déploiement.

Se produit pendant : l'exécution des tests Apex dans le cadre d'un déploiement ou d'une validation

Ce que cela signifie

CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY est une erreur DML générique que Salesforce déclenche lorsqu'un déclencheur (trigger), une règle de validation ou une automatisation de processus dans l'org cible rejette un enregistrement. Elle apparaît le plus souvent pendant l'exécution des tests Apex, car un déploiement en production ou une validation exécute toujours vos tests contre la pile d'automatisation réelle de l'org cible.

Comme il s'agit d'un code générique, le détail utile se trouve presque toujours dans le texte qui le suit dans le résultat du déploiement, le message précis de la règle de validation, l'exception du trigger ou l'échec du flow, pas dans le code lui-même.

Diagnostic

Causes courantes

Une règle de validation rejette les données de test
La data factory d'un test Apex ne satisfait pas une règle de validation qui n'est active que dans l'org cible.
Des effets secondaires de l'automatisation échouent
Un trigger ou un flow exécute une opération DML qui atteint une limite gouverneur (governor limit) ou rencontre un enregistrement verrouillé pendant l'exécution du test.
Configuration spécifique à l'environnement manquante
L'org cible ne dispose pas d'un custom setting, d'un type d'enregistrement par défaut ou d'une autre configuration dont dépend l'automatisation.

La solution

  1. Lisez le texte complet de l'erreur, pas seulement le code
    Ouvrez le résultat du déploiement et lisez ce qui suit CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY ; Salesforce ajoute le message précis de la règle de validation ou du trigger qui identifie l'échec réel.
  2. Alimentez d'abord la configuration requise
    Déployez les custom settings, les custom metadata ou les types d'enregistrement par défaut dont l'automatisation a besoin avant d'exécuter les tests qui en dépendent.
  3. Isolez l'automatisation en cause
    Désactivez temporairement ou contournez le trigger ou le flow spécifique dans une scratch org pour confirmer quelle automatisation rejette l'enregistrement.
En pratique

Comment Serpent évite cela

Serpent AI exécute vos tests Apex contre l'org cible réelle avant le déploiement effectif, de sorte qu'un enregistrement rejeté apparaît comme une règle de validation ou un trigger nommé, et non comme un échec générique. Consultez 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 vos data factories de tests Apex sur des règles de validation proches de la production
Maintenez une data factory de test partagée qui satisfait chaque règle de validation active, afin que les nouveaux tests héritent de données conformes plutôt que de créer manuellement des enregistrements qui ignorent les cas limites.
Déployez les dépendances de configuration dans la même tâche que l'automatisation qui en a besoin
Regroupez les custom settings, les custom metadata et les types d'enregistrement par défaut avec le trigger ou le flow qui les lit, afin qu'ils n'arrivent jamais dans le désordre dans l'org cible.
Validez sur un clone de l'org cible avant une release en production
Exécutez un déploiement en mode vérification uniquement (check-only) sur une sandbox complète qui reflète les règles de validation et l'automatisation de la production avant la véritable fenêtre de release.
Questions fréquentes

CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, expliqué

Le message d'erreur m'indique-t-il quelle règle de validation a échoué ?
En général, oui. Salesforce ajoute le texte d'erreur propre à la règle de validation ou au trigger après le code CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, donc lisez au-delà du code lui-même.
Pourquoi le déploiement échoue-t-il ici alors que le même test réussit dans ma sandbox de développement ?
Les règles de validation, les flows et les custom settings diffèrent souvent entre une sandbox de développement personnelle et l'org cible. Comparez l'automatisation active sur l'objet concerné entre les deux environnements.
Cela peut-il parfois être un bug de Salesforce plutôt qu'un problème de configuration de mon org ?
Rarement. Ce code reflète presque toujours l'automatisation propre à l'org cible qui rejette l'enregistrement comme prévu ; traitez-le d'abord comme un problème de configuration ou de données de test.

Démarrez gratuitement. Pas de carte bancaire, pas d'installation, pas d'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.