Dans ServiceNow, il existe plusieurs façons de contrôler le comportement et la validation des données. Deux des plus utilisées sont les Business Rules et les Client Scripts.
Mais comment choisir entre les deux ? Quelle est la différence ? Et surtout, quelles sont les bonnes pratiques à adopter pour offrir à la fois une bonne expérience utilisateur et une protection efficace des données ?
Voici une explication simple et concrète.
Client Script : pour guider l’utilisateur
Un Client Script s’exécute dans le navigateur de l’utilisateur (côté client). Il permet de :
- Afficher ou masquer des champs
- Rendre un champ obligatoire ou en lecture seule
- Pré-remplir des champs automatiquement
- Alerter l’utilisateur avant l’envoi du formulaire
Avantages :
- Rapide : la vérification se fait instantanément, sans appel serveur
- Ergonomique : l’utilisateur voit immédiatement ce qui ne va pas
- Idéal pour des règles simples, de type “UX”
Limites :
- Facile à contourner : les modifications via API, import, édition en liste ou script serveur ne passent pas par le navigateur
- Ne garantit pas l’intégrité des données côté serveur
Business Rule : pour sécuriser les données
Une Business Rule s’exécute côté serveur, à différents moments du cycle de vie d’un enregistrement (avant ou après insert/update/delete).
Elle sert à :
- Vérifier ou forcer des valeurs
- Bloquer des actions si certaines conditions ne sont pas respectées
- Automatiser des traitements complexes
Avantages :
- Sécurisée : elle s’applique même si l’utilisateur utilise l’API, l’import Excel, les scripts, ou l’édition en liste
- Permet de rejeter une modification avec un message d’erreur explicite
Limites :
- Moins fluide pour l’utilisateur : le feedback n’arrive qu’après soumission du formulaire
- Nécessite un appel serveur
Quel outil choisir ?
La bonne question à se poser est :
“Si quelqu’un modifie l’enregistrement via l’API, l’édition en liste ou un script, et que cette règle est violée… que doit-il se passer ?”
Si la réponse est :
“Je veux empêcher la modification avec un message d’erreur”, alors il faut utiliser une Business Rule (ou une Data Policy).
Cela garantit l’intégrité des données côté serveur, quel que soit le canal utilisé.
Si la réponse est :
“Ce n’est pas bloquant, je veux juste guider l’utilisateur”, alors un Client Script ou une UI Policy suffisent.
C’est idéal pour améliorer l’expérience utilisateur sans complexité serveur.
Bonne pratique : combiner les deux
“Prévenir plutôt que punir”
Même si vous appliquez une règle côté serveur, ajoutez une validation côté client pour informer l’utilisateur avant qu’il clique sur “Soumettre”.
Exemple :
- Côté client : un champ devient obligatoire dès qu’une case est cochée
- Côté serveur : une Business Rule bloque la sauvegarde si ce champ est vide
Cela évite les surprises, les frustrations, et rend l’application plus intuitive.
Pour des applications solides dans ServiceNow :
- Utilisez les Client Scripts pour une interface réactive et conviviale
- Sécurisez avec des Business Rules ce qui doit absolument être respecté
- Combinez les deux pour éviter les erreurs et guider l’utilisateur intelligemment
Parce qu’une bonne UX, ce n’est pas seulement faire joli — c’est aussi éviter les erreurs… avant qu’elles n’arrivent.