La question revient à chaque revue de code : cette logique, on la met dans une Business Rule ou dans un flow ? Le débat se règle souvent par une préférence personnelle, ou par une consigne interne du type « on ne fait plus de script ». Les deux mènent au même endroit, une plateforme où la moitié de l'automatisation est au mauvais endroit.
Le critère utile n'est ni le confort du développeur ni la doctrine low-code. C'est la position de la logique par rapport à la transaction de base de données. Une Business Rule vit dedans. Un flow, par défaut, vit dehors. Tout le reste découle de là.
Cet article pose les faits de fonctionnement des deux outils, puis un tableau de décision par cas d'usage, utilisable en revue de conception.
La question n'est pas low-code contre script
Flow Designer contient des scripts, dans les actions personnalisées et dans les conditions en ligne. Une Business Rule bien écrite peut ne contenir aucune ligne au delà d'un appel à un Script Include. L'opposition entre visuel et code ne décrit donc rien d'utile.
Ce qui distingue réellement les deux outils tient en trois questions :
La logique doit-elle s'exécuter avant l'écriture en base, ou peut-elle attendre ?
L'utilisateur doit-il attendre la fin du traitement ?
Le traitement a-t-il besoin de faire une pause, d'attendre une approbation ou une condition ?
Une Business Rule répond correctement aux deux premières et pas du tout à la troisième. Un flow répond à la troisième, à la deuxième dans certaines configurations, et pas à la première.
Business Rule : quatre moments d'exécution
Une Business Rule est un script serveur déclenché par une opération de base de données : insertion, mise à jour, suppression, requête. Le champ When définit quatre comportements très différents, et le choix de ce champ compte davantage que le contenu du script.
Before. Le script s'exécute dans la même transaction, avant l'écriture. C'est le seul moment où l'on peut modifier la valeur qui sera enregistrée, en affectant directement current.champ, sans appeler update(). C'est aussi le seul endroit où l'on peut annuler l'opération.
// Business Rule before, sur incident, insert et update
(function executeRule(current, previous) {
if (current.impact == 1 && current.urgency == 1) {
current.priority = 1;
}
// pas de current.update() : l'ecriture n'a pas encore eu lieu
})(current, previous);After. Le script s'exécute dans la même transaction, après l'écriture. L'utilisateur attend sa fin avant de récupérer la main. C'est le bon endroit pour agir sur d'autres enregistrements, jamais pour modifier l'enregistrement courant, ce qui déclencherait une écriture supplémentaire et un risque de récursion.
Async. À la validation, la plateforme crée un travail planifié, matérialisé par un enregistrement dans sys_trigger, exécuté en arrière plan une fois la transaction terminée. L'utilisateur reprend la main immédiatement. Point à connaître : l'objet previous n'est pas disponible dans une Business Rule async. Toute logique fondée sur la valeur précédente d'un champ y est donc impossible.
Display. Le script s'exécute avant l'affichage du formulaire, et sert à préparer des données côté serveur pour le client via g_scratchpad.
Deux réglages méritent d'être traités avec autant d'attention que le script lui même. Le champ Order détermine la séquence d'exécution, et deux règles portant le même ordre n'ont pas de séquence garantie entre elles. Le champ Condition, lui, doit porter le filtre le plus restrictif possible : une condition écrite là évite le chargement et l'exécution du script, ce qu'un if en tête de script ne fait pas.
Flow Designer : hors transaction par défaut
Un flow déclenché sur création ou mise à jour d'enregistrement ne s'exécute pas dans la transaction utilisateur. Il part en arrière plan, comme un travail planifié. Il existe toujours un délai entre l'opération de base de données et le démarrage effectif du flow.
Cette caractéristique est un avantage et un piège. Un avantage, parce que le temps de traitement n'est pas facturé à l'utilisateur et n'entre pas dans la limite de temps de la transaction interactive. Un piège, parce que la donnée lue par le flow est celle qui existe au moment où il démarre, pas celle qui existait au moment du déclenchement.
Le cas d'école est le commentaire. Un flow déclenché sur ajout de commentaire et exécuté en arrière plan lit le champ au démarrage. Si un second commentaire est arrivé entre temps, le flow traite le mauvais texte.
Deux réglages du déclencheur changent ce comportement :
Run Trigger définit si le flow part une seule fois, ou à chaque modification distincte remplissant la condition.
Dans les options avancées, Where to run the flow permet de basculer d'un fonctionnement en arrière plan, qui est le réglage par défaut, à une exécution au premier plan. Le flow rejoint alors la transaction utilisateur, avec accès à l'enregistrement déclencheur tel qu'il est à cet instant, et avec le coût correspondant sur le temps de réponse.
Un flow apporte en revanche quelque chose qu'aucune Business Rule ne sait faire : la mise en attente. Attendre une approbation, attendre une condition, attendre un délai, reprendre là où l'on s'était arrêté. Une Business Rule s'exécute d'un bloc et se termine.
Dernier point de vigilance : chaque exécution produit un contexte de flow persisté. Une boucle For Each sur plusieurs centaines ou milliers d'enregistrements construit un contexte volumineux et coûte cher. Sur ces volumes, la bonne pratique consiste à confier le traitement à une action scriptée à l'intérieur du flow, plutôt qu'à la boucle native.
Le critère qui tranche
Posez la question dans cet ordre, et la réponse tombe presque toujours d'elle même.
La logique doit-elle influencer la valeur enregistrée ? Si oui, Business Rule before. Aucune autre réponse n'existe.
La logique doit-elle empêcher l'enregistrement ? Si oui, Business Rule before, avec
setAbortAction.La logique a-t-elle besoin de la valeur précédente d'un champ ? Si oui, Business Rule before ou after, jamais async, jamais un flow en arrière plan.
La logique doit-elle attendre quelque chose ou quelqu'un ? Si oui, flow, sans hésitation.
Sinon, flow.
Ce dernier point est volontairement large. Une fois écartés les trois premiers cas, un flow est presque toujours préférable : il est lisible sans lire de code, ses exécutions sont tracées et rejouables, et il n'alourdit pas la transaction utilisateur.
Le tableau de décision
Cas par cas, voici ce que nous appliquons en revue de conception.
Calculer un champ avant l'enregistrement. Business Rule before. La valeur doit exister avant l'écriture.
Refuser un enregistrement selon une règle métier. Business Rule before. Un flow ne peut pas annuler une opération déjà commise.
Réagir à un changement de valeur précis, ancien vers nouveau. Business Rule before ou after, pour disposer de
previous.Mettre à jour des enregistrements liés. Flow, ou Business Rule async si la logique est courte et déjà en place.
Envoyer une notification conditionnelle complexe. Flow.
Faire approuver, puis continuer. Flow. C'est le cas d'usage qui exclut totalement la Business Rule.
Appeler un système externe. Flow avec IntegrationHub, jamais une Business Rule synchrone : un appel externe dans une transaction utilisateur expose à un temps de réponse hors de votre contrôle.
Traiter un lot volumineux. Flow déclenché par planification, avec une action scriptée pour la boucle, ou travail planifié classique.
Préparer des données pour le formulaire. Business Rule display. Aucun flow ne couvre ce besoin.
Filtrer ce qu'un utilisateur peut voir dans une liste. Business Rule de type query, et rien d'autre.
Lire un commentaire ou une note de travail au moment exact de l'ajout. Flow au premier plan, ou Business Rule after qui transmet la valeur au flow.
Quatre erreurs qui coûtent cher
Une Business Rule before qui fait un travail d'arrière plan. Appel REST, boucle sur cent enregistrements, génération de document : tout cela s'ajoute au temps d'enregistrement, sur chaque sauvegarde, pour chaque utilisateur. C'est la première cause de formulaires lents.
Une Business Rule after qui met à jour l'enregistrement courant. Elle provoque une seconde écriture, qui redéclenche les règles, et parfois une boucle. La bonne réponse est presque toujours de déplacer la logique en before.
Un flow déclenché sur une table à fort volume sans condition restrictive. Chaque exécution crée un contexte. Sur une table qui reçoit des milliers d'écritures par jour, la facture arrive sous forme de lenteur générale, difficile à rattacher à sa cause.
Une chaîne Business Rule vers flow vers Business Rule. Techniquement possible, illisible en production. Quand un incident survient, personne ne sait plus quel maillon a modifié quoi. Si vous devez chaîner, documentez le point d'entrée dans la description de chaque objet.
Faire cohabiter les deux
Les deux outils ne s'excluent pas. Le motif le plus utile consiste à capturer la donnée dans une Business Rule, au moment où elle est fiable, puis à confier le traitement long à un flow.
// Business Rule after : on capture la valeur, le flow fait le reste
(function executeRule(current, previous) {
var inputs = {};
inputs['record'] = current;
inputs['comment'] = current.comments.getJournalEntry(1);
sn_fd.FlowAPI.getRunner()
.subflow('global.traitement_commentaire')
.inBackground()
.withInputs(inputs)
.run();
})(current, previous);inForeground() exécute le flow dans la transaction et attend sa fin. inBackground() rend la main immédiatement. Le choix entre les deux est exactement le même arbitrage que celui décrit plus haut, simplement déplacé dans le code.
Et les Workflow historiques ?
Une précision utile, parce que le sujet circule de travers. À la date de rédaction, l'équipe produit ServiceNow indique qu'il n'existe pas de plan de dépréciation du moteur Workflow historique. En revanche, depuis la famille Zurich, les nouvelles instances ne sont plus livrées avec des workflows historiques en standard, et la recommandation constante est de construire toute nouvelle automatisation dans Flow Designer.
La conséquence pratique : rien ne vous oblige à migrer en urgence, mais tout ce qui est construit aujourd'hui dans l'ancien éditeur est de la dette. Vérifiez ce point sur la documentation de votre version avant d'engager un chantier de migration.
Par où commencer
Si vous héritez d'une instance et que vous voulez savoir où vous en êtes, trois requêtes suffisent à cadrer le sujet.
Lister les Business Rules actives par table, triées par nombre, et regarder d'abord les tables transactionnelles principales.
Isoler les Business Rules before dont le script dépasse une trentaine de lignes ou contient un appel externe. Ce sont les candidates prioritaires à un déplacement vers un flow.
Vérifier les Business Rules sans condition, qui s'exécutent donc sur chaque écriture de leur table.
Le tri se fait ensuite avec le tableau ci dessus. La règle générale tient en une phrase : ce qui doit modifier ou bloquer l'écriture reste une Business Rule before, ce qui vient après appartient à un flow.