Comprendre et configurer les règles de validation

Les règles de validation sont l'outil déclaratif le plus direct pour garantir la qualité des données à la saisie. Simples en apparence, elles sont pourtant à l'origine de nombreux blocages utilisateurs et conflits avec les automatisations lorsqu'elles sont mal conçues. Voici comment les construire proprement.

Principe de fonctionnement

Une règle de validation (Configuration > Générateur d'objets > [Objet] > Règles de validation) repose sur une formule qui doit être vraie pour bloquer l'enregistrement. C'est un point souvent mal compris : la formule décrit la condition d'erreur, pas la condition de succès. Par exemple, pour exiger un champ Téléphone sur un Contact :

• Formule : ISBLANK(Phone)
• Si la formule est vraie (le champ est vide), Salesforce bloque l'enregistrement et affiche le message d'erreur défini.

Chaque règle s'exécute à chaque enregistrement (création ou modification) et peut être limitée à certains contextes grâce à des fonctions comme ISNEW(), ISCHANGED() ou PRIORVALUE().

Fonctions essentielles à maîtriser

• ISNEW() : vrai uniquement à la création, utile pour ne contraindre que la saisie initiale.
• ISCHANGED(champ) : vrai si le champ a été modifié lors de cette transaction, pour éviter de rejeter des enregistrements existants non touchés par le changement.
• PRIORVALUE(champ) : récupère la valeur avant modification, utile pour interdire un retour en arrière (ex. empêcher de repasser un statut « Clôturé » à « Ouvert »).
• ISBLANK() / ISNULL() : vérifient si un champ est vide (texte ou numérique/date respectivement).
• REGEX() : valide un format précis (ex. code postal, SIRET) via une expression régulière.
• $Profile.Name ou $UserRole.Name : permettent de cibler la règle sur un profil ou rôle spécifique, pour ne pas bloquer les intégrations ou l'équipe support.

Exemple concret : rendre un champ obligatoire selon le statut

Pour exiger un motif de perte uniquement quand une opportunité passe au statut « Perdue » :

AND(
  ISPICKVAL(StageName, "Closed Lost"),
  ISBLANK(Loss_Reason__c)
)

Cette formule ne se déclenche que lorsque le stade est précisément « Closed Lost » ET que le champ motif est vide, sans jamais gêner les autres statuts.

Ordre d'exécution et interactions à connaître

Les règles de validation s'exécutent après les règles d'affectation et les valeurs par défaut, mais avant l'enregistrement en base et avant les triggers Apex « before ». Elles interviennent également après les Flows à enregistrement déclenché en mode « before save ». Cela signifie qu'une règle de validation peut bloquer un Flow qui tente de mettre à jour un champ vers un état non conforme — une source fréquente de bugs difficiles à diagnostiquer.

Piège fréquent : une règle de validation trop stricte bloque les imports en masse (Data Loader) ou les intégrations API qui ne passent pas par l'interface utilisateur habituelle. Prévoyez toujours une exception pour le profil d'intégration via $Profile.Name != "Integration User" lorsque c'est pertinent.

Bonnes pratiques de conception

1. Un message d'erreur clair et actionnable : indiquez précisément quel champ corriger et pourquoi, idéalement en l'associant au champ concerné plutôt qu'en haut de page.
2. Nommez vos règles de façon descriptive (ex. Opportunity_LossReason_Required) et documentez l'objectif métier dans la description.
3. Centralisez la logique complexe dans des champs formule cachés plutôt que de dupliquer une même formule dans plusieurs règles.
4. Testez les scénarios de mise à jour en masse et d'import avant le déploiement : une règle qui fonctionne bien en saisie manuelle peut bloquer des milliers d'enregistrements lors d'une migration.
5. Évitez la prolifération : au-delà d'une dizaine de règles actives sur un objet très utilisé, envisagez de consolider ou de migrer certaines vérifications vers un Flow avec des messages d'erreur contextualisés.

Désactivation temporaire et audit

Chaque règle dispose d'une case « Active » permettant de la désactiver sans la supprimer, très utile lors d'une migration de données ponctuelle. Pensez à consigner (et réactiver systématiquement après coup) toute désactivation temporaire ; c'est l'une des causes les plus fréquentes de données incohérentes découvertes bien plus tard.

Bien conçues, les règles de validation sont un filet de sécurité léger et sans code qui protège la qualité de vos données sans avoir besoin de développement Apex.