Comment corriger FIELD_CUSTOM_VALIDATION_EXCEPTION dans les déploiements Salesforce

Une validation rule personnalisée dans l'org cible a bloqué l'enregistrement, et le texte de l'erreur est le message même de la règle.

Se produit lors de : DML à l'exécution, le plus souvent pendant l'exécution de tests Apex

Ce que cela signifie

FIELD_CUSTOM_VALIDATION_EXCEPTION signifie qu'une validation rule que vous ou un autre admin avez configurée a rejeté l'enregistrement en cours d'enregistrement. Salesforce ajoute le message d'erreur exact de la validation rule à l'exception, donc la correction est généralement visible directement dans le texte de l'erreur, une fois que vous savez quel enregistrement et quelle règle l'ont déclenchée.

Parce que les déploiements en production exécutent les tests Apex contre les véritables validation rules actives de la production, c'est l'une des façons les plus courantes dont une validation rule qui fonctionnait bien dans un sandbox bloque une release : le sandbox n'avait tout simplement pas cette règle activée.

Diagnostic

Causes courantes

Les données de test ne satisfont pas la règle
La factory de données d'un test Apex construit des enregistrements qui enfreignent une validation rule active dans l'org cible mais pas dans le sandbox source.
Validation rule incohérente entre les environnements
L'état d'activation ou la logique de la règle diffère entre les environnements parce qu'un changement n'a pas été promu partout.
Une nouvelle règle entre en conflit avec les schémas de données existants
Une validation rule ajoutée dans le même déploiement entre en conflit avec la façon dont l'automatisation ou les tests existants construisent les enregistrements.

La solution

  1. Lisez le texte d'erreur propre à la règle
    Le message après le code d'erreur nomme la condition exacte qui a échoué ; commencez par là au lieu de deviner.
  2. Mettez à jour la factory de données de test
    Ajustez la configuration du test Apex afin que les enregistrements générés respectent la condition de la validation rule.
  3. Alignez l'activation de la règle entre les orgs
    Confirmez que la validation rule est activée (ou désactivée) de façon cohérente dans chaque environnement touché par le déploiement.
En pratique

Comment Serpent évite cela

Serpent AI affiche le message exact de la validation rule dès le preflight, avant l'exécution du déploiement réel, afin que vous corrigiez la règle ou les données une seule fois au lieu de deviner. 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

Déployez les validation rules avec la même rigueur que le code Apex
Suivez les changements de validation rules dans le contrôle de source et faites-les transiter par le même pipeline que le code, au lieu de les modifier de façon ad hoc dans Setup d'un org.
Construisez les factories de données de test à partir des règles actives de l'objet, pas d'un savoir tribal
Passez en revue chaque validation rule active sur un objet lors de la rédaction de sa factory de données de test, plutôt que de vous fier à ce qui passait par le passé.
Validez contre un sandbox proche de la production avant la release
Exécutez un déploiement check-only contre un sandbox complet avec les véritables validation rules de production actives, afin qu'un écart de règle apparaisse avant la fenêtre de release, pas pendant.
Questions fréquentes

FIELD_CUSTOM_VALIDATION_EXCEPTION, les réponses

Est-il sûr de simplement désactiver la validation rule pendant le déploiement ?
Uniquement en dernier recours, et jamais en production. Corriger les données de test ou l'enregistrement sous-jacent est plus sûr que de désactiver une règle qui protège des données réelles.
Une validation rule peut-elle se déclencher sur un champ invisible dans le page layout ?
Oui. Les validation rules évaluent les valeurs de champ enregistrées de l'enregistrement quelle que soit la visibilité dans le page layout, donc un champ masqué peut toujours bloquer un enregistrement.
Pourquoi le même test réussit-il seul mais échoue-t-il dans la suite complète ?
Un autre test exécuté plus tôt a probablement modifié un état partagé, un custom setting, un enregistrement que la validation rule vérifie, que les données du test en échec violent désormais. Isolez le test antérieur pour confirmer.

Commencez gratuitement. Sans carte bancaire, sans installation, sans engagement.

Configuration en moins de 15 minutes. Aucune embauche DevOps nécessaire.

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

Sans engagement.