Règles de validation Salesforce : 3 conseils pour les admins

La plupart des organisations Salesforce ont des règles de validation. Beaucoup moins ont des règles que les utilisateurs apprécient. Écrites trop vite, elles produisent des messages flous, font échouer les imports au milieu de la nuit et poussent les admins à les désactiver « juste pour aujourd'hui ». Ce guide réunit des conseils concrets pour écrire une règle de validation Salesforce efficace dès cet après-midi : la formule, le message d'erreur, les anciens enregistrements et un contournement maîtrisé pour les chargements de données.

Comment fonctionne une règle de validation Salesforce

Une règle de validation contrôle un enregistrement au moment de son enregistrement. Si les données enfreignent votre règle métier, l'enregistrement est bloqué et l'utilisateur voit un message d'erreur qui lui demande de corriger la saisie. Le module Trailhead Création de règles de validation présente cette logique en français. Salesforce cite trois usages classiques : le format des données (longueur, plage, motif), le processus métier (ce qui doit être renseigné à chaque étape) et la conformité.

Le déclic à avoir : la formule de condition d'erreur décrit la mauvaise donnée, pas la bonne. Quand la formule renvoie TRUE, l'erreur s'affiche. Inutile de l'envelopper dans IF(condition, TRUE, FALSE) : la condition renvoie déjà TRUE ou FALSE.

Pour en créer une :

1. Dans Setup, ouvrez Object Manager (Gestionnaire d'objets) et choisissez l'objet, par exemple Compte.
2. Dans la barre latérale, cliquez sur Validation Rules (Règles de validation), puis sur New (Nouveau).
3. Saisissez un nom de règle et une description qui explique la raison métier.
4. Écrivez la formule de condition d'erreur. Utilisez Insert Field (Insérer un champ) plutôt que de taper les noms : les formules utilisent les noms d'API (l'étape d'une opportunité s'appelle StageName), et les noms devinés sont la première cause d'erreurs de syntaxe.
5. Rédigez le message d'erreur et choisissez l'emplacement de l'erreur.
6. Cliquez sur Check Syntax (Vérifier la syntaxe), puis sur Save (Enregistrer), et vérifiez que la règle est active.

Un exemple simple tiré de Trailhead : un numéro de compte, s'il est renseigné, doit comporter exactement huit caractères. La formule est AND(NOT(ISBLANK(AccountNumber)), LEN(AccountNumber) != 8). Lisez-la ainsi : « le champ n'est pas vide ET sa longueur n'est pas 8 ». C'est le cas à bloquer.

Conseil 1 : des messages d'erreur que l'utilisateur corrige seul

Un message d'erreur fait partie de l'interface. Rédigez-le comme tel. Le module Trailhead sur les bonnes pratiques des règles de validation (en anglais) recommande trois habitudes rentables :

• Dire ce qui a déclenché la règle et comment corriger. « Le montant est obligatoire à partir de l'étape Qualification. Saisissez un montant ou revenez à l'étape précédente » vaut mieux que « Données non valides ».
• Ajouter un code d'erreur unique à chaque message, avec un préfixe par objet (OPP001, OPP002, LEAD001…). Quand un utilisateur envoie une capture d'écran, ou quand un flow échoue à cause d'une règle sur un enregistrement lié, le code vous mène à la bonne règle en quelques secondes.
• Afficher l'erreur sur le champ dès que possible. Salesforce ajoute alors un lien qui amène l'utilisateur directement au champ à corriger. Gardez l'affichage en haut de page pour les règles qui portent sur plusieurs champs.

Autre principe du même module : un scénario par règle. Si une opportunité exige à la fois un montant et des prochaines étapes à un stade donné, créez deux règles. Chaque formule reste lisible, chaque erreur s'affiche sur son propre champ, et vous pouvez en désactiver une sans toucher à l'autre.

Conseil 2 : ne plus bloquer les anciens enregistrements

La plainte classique : un commercial modifie le téléphone d'une opportunité vieille de trois ans et se retrouve bloqué parce que la date de clôture est passée. La règle est juste pour les nouvelles données, mais elle pénalise un historique que l'utilisateur n'a pas créé.

La solution consiste à ne faire réagir la règle qu'aux changements pertinents, avec trois fonctions :

• ISNEW() renvoie TRUE lorsque l'enregistrement est en cours de création.
• ISCHANGED(champ) renvoie TRUE lorsque la valeur du champ a changé lors de cet enregistrement. Elle ne détecte rien à la création : associez-la à ISNEW().
• PRIORVALUE(champ) renvoie la valeur précédente. Utile pour verrouiller un champ une fois un état atteint, par exemple empêcher toute modification après une opportunité gagnée (Closed Won).

L'exemple Trailhead sur la date de clôture combine ces fonctions : il ne bloque que si l'enregistrement est nouveau ou si la date de clôture a changé, et que la nouvelle date est antérieure à TODAY(). Avant et après, concrètement :

Avant (règle sans détection de changement) :

• Toute modification d'une opportunité dont la date de clôture est passée est bloquée.
• Les utilisateurs appellent l'admin, ou la règle finit désactivée.

Après (règle avec ISNEW() ou ISCHANGED(CloseDate)) :

• Impossible de créer une opportunité avec une date de clôture passée.
• Impossible de déplacer une date de clôture existante dans le passé.
• Les autres champs des anciennes opportunités restent modifiables.

Deux autres fonctions à connaître : ISPICKVAL() pour tester une valeur de liste de sélection, et TEXT() pour vérifier qu'une liste de sélection est vide (par exemple ISBLANK(TEXT(Industry))). Pour d'autres modèles, l'aide Salesforce propose une bibliothèque d'exemples de règles de validation par objet (en anglais) : comptes, contacts, dates, nombres, gestion des opportunités, etc.

Conseil 3 : un contournement maîtrisé avec une autorisation personnalisée

Migrations, corrections en masse et intégrations doivent parfois enregistrer des données qu'une règle refuserait. Désactiver la règle pour tout le monde est risqué. Le module Trailhead sur le contournement des règles de validation (en anglais) décrit une méthode plus propre en trois étapes :

1. Dans Setup, créez une autorisation personnalisée (custom permission), par exemple Bypass_Lead_Validation_Rules, avec une description qui explique son rôle.
2. Créez un ensemble d'autorisations (licence : aucune), activez-y cette autorisation personnalisée et attribuez-le uniquement aux utilisateurs qui en ont besoin, comme l'utilisateur d'intégration ou la personne qui pilote une migration.
3. Ajoutez NOT($Permission.Bypass_Lead_Validation_Rules) comme première condition d'un AND() dans chaque règle concernée.

Trailhead propose une variante encore plus sûre : un ensemble d'autorisations basé sur la session, activé par un flow, pour que le contournement reste désactivé par défaut et ne s'active que lorsque la situation l'exige.

Utilisez-le avec parcimonie. Une règle bien écrite avec ISNEW() et ISCHANGED() en a rarement besoin, et des données enregistrées en contournement peuvent bloquer d'autres utilisateurs lors de leur prochaine modification. Si vous préparez un chargement important, notre guide pour configurer les règles de duplication Salesforce couvre l'autre moitié de la qualité des données, et notre page migrations CRM explique comment nous planifions les chargements sans couper les contrôles à l'aveugle.

Que faire maintenant : revue de vos règles en 30 minutes

Choisissez un objet (l'opportunité est souvent le meilleur point de départ) et passez cette liste de contrôle :

• Inventaire : ouvrez Object Manager, puis Validation Rules, et listez chaque règle active avec sa description. Une règle que personne ne sait expliquer est candidate à la suppression.
• Codes d'erreur : chaque message commence-t-il par un code et dit-il comment corriger ?
• Emplacement : chaque règle portant sur un seul champ affiche-t-elle l'erreur sur ce champ ?
• Historique : chaque règle utilise-t-elle ISNEW(), ISCHANGED() ou PRIORVALUE() quand c'est pertinent, pour que les anciens enregistrements restent modifiables ?
• Contournement : existe-t-il une autorisation personnalisée documentée pour les intégrations et les chargements, plutôt que des règles désactivées au coup par coup ?
• Automatisation : Trailhead rappelle que les flows et les triggers peuvent modifier des valeurs avant l'évaluation de la règle. Si un flow met à jour un champ contrôlé, l'utilisateur peut être bloqué par un changement qu'il n'a pas fait. Ajoutez un chemin d'erreur à ces flows, comme expliqué dans notre article sur la gestion des erreurs Flow Salesforce.

Testez ensuite chaque règle modifiée sur quatre cas : création d'un enregistrement avec une donnée invalide, modification du champ contrôlé vers une valeur invalide, puis vers une valeur valide, et modification d'un autre champ sur un ancien enregistrement. Les quatre doivent se comporter comme prévu avant le passage en production.

Conclusion

Une bonne règle de validation est courte, précise et discrète : elle ne se manifeste que lorsque la donnée est réellement fausse, et elle dit exactement quoi faire. Des messages codés, la détection de changement avec ISNEW() et ISCHANGED(), et un contournement unique et documenté suppriment l'essentiel des frictions que les admins gèrent au quotidien.

Si votre organisation a accumulé des dizaines de règles au fil des années sans que personne ne sache lesquelles servent encore, une revue structurée de votre configuration Salesforce Sales Cloud est souvent le moyen le plus rapide de faire le ménage sans casser un processus commercial en place.