Les Business Rules sont l’un des premiers outils qu’on apprend sur ServiceNow, et aussi l’un des plus mal utilisés. Choisir le mauvais moment d’exécution, c’est la garantie de bugs difficiles à traquer et de performances qui s’effondrent. Dans cet article, on clarifie les 4 types, ce qu’ils font vraiment, et comment choisir le bon à chaque fois.
C’est quoi une Business Rule ?
Une Business Rule est un script serveur qui se déclenche quand un enregistrement est inséré, modifié, supprimé ou interrogé dans une table. Elle s’exécute côté serveur, jamais dans le navigateur. On la configure sur une table donnée, avec des conditions et un moment d’exécution.
Ce moment d’exécution est le cœur du sujet : il existe quatre choix, et chacun répond à un besoin précis.
1. Before — avant l’écriture en base
La règle s’exécute après validation mais avant que l’enregistrement soit écrit en base. C’est le moment idéal pour modifier des valeurs sur l’enregistrement courant, car tes changements sont sauvegardés automatiquement, sans update().
Usage typique : remplir un champ automatiquement, normaliser une donnée, ou bloquer une opération avec current.setAbortAction(true).
2. After — après l’écriture en base
La règle s’exécute une fois l’enregistrement écrit. À ce stade, modifier current ne sert plus à rien pour l’enregistrement lui-même. On l’utilise pour agir sur d’autres enregistrements : mettre à jour un ticket lié, créer une tâche, déclencher une notification.
3. Async — en arrière-plan, après la transaction
Comme une After, mais l’exécution est mise en file d’attente (via le scheduler) et se fait après la transaction, sans faire attendre l’utilisateur. Parfait pour les traitements lourds ou les intégrations externes qui ne doivent pas ralentir l’enregistrement. À privilégier dès que le résultat n’a pas besoin d’être immédiat.
4. Display — avant l’affichage du formulaire
La règle s’exécute quand le formulaire se charge, avant qu’il s’affiche. Son rôle unique : passer des données serveur au client via l’objet g_scratchpad, pour les récupérer ensuite dans un Client Script sans faire d’appel supplémentaire.
Comment choisir en une question
Pose-toi : « À quel moment ai-je besoin d’agir ? »
Modifier l’enregistrement courant → Before. Agir sur d’autres enregistrements → After. Traitement lourd ou intégration → Async. Préparer des données pour le formulaire → Display.
Bonnes pratiques
Mets toujours des conditions précises pour éviter les exécutions inutiles. Encapsule ta logique dans un Script Include appelé depuis la Business Rule, plutôt que d’écrire tout le code directement dedans. Et privilégie Async dès que possible : l’expérience utilisateur te remerciera.
Conclusion
Maîtriser les 4 types de Business Rules, c’est comprendre le cycle de vie d’un enregistrement dans ServiceNow. Une fois ce réflexe acquis, tu écris un code plus propre, plus rapide, et bien plus facile à maintenir.
