Restreindre une règle par une condition

Filtre sans code ou expression CEL, variables avant et après l'événement, et conditions de transition

À quoi ça sert

Un déclencheur est large : « à la modification d'un champ » part pour toutes les fiches de l'entité. La condition est ce qui ramène la règle aux seuls cas visés : seulement les opportunités gagnées, seulement les contrats d'un modèle donné, seulement les factures de plus de 1 000 euros.

Une condition existe à deux niveaux, avec le même éditeur : au niveau de la règle, où elle décide si la règle s'exécute du tout, et au niveau d'une action, où elle décide si cette action précise s'exécute. Une action dispose en plus du mode « Recherche », qui consulte les tâches ou les fiches CRM existantes.

Une règle au déclencheur « Date » n'a pas de condition : n'ayant pas de fiche déclencheuse, il n'y a rien à évaluer. Le bloc « Condition » disparaît du formulaire pour une telle règle. Voir Choisir un déclencheur.

Une condition fausse au niveau de la règle n'enregistre rien : aucune exécution n'apparaît dans le suivi. Une condition fausse au niveau d'une action laisse une trace : l'action est marquée « ignorée ».

Concepts clés

Toujours — pas de condition, la règle s'exécute à chaque déclenchement.
Filtre — le constructeur visuel de filtres, le même que dans les listes de l'application. On choisit un champ, un opérateur et une valeur, et on combine plusieurs critères. Aucune écriture n'est nécessaire.
Expression (CEL) — une expression écrite qui doit renvoyer vrai ou faux. Elle donne accès à l'état antérieur et aux comparaisons que le filtre ne sait pas exprimer.
Recherche — un mode réservé aux conditions d'action. L'action s'exécute selon qu'une tâche ou une fiche CRM répondant à vos critères existe déjà ou non. C'est ce qui permet de créer une fiche ou une tâche seulement si elle n'existe pas encore.
record — l'objet déclencheur après l'évènement. Chaque champ est lu par son nom technique : record.status, record.amount. Un champ non renseigné vaut la valeur vide.
before — le même objet tel qu'il était avant l'évènement, avec les mêmes noms de champs.
after — un autre nom pour record, pour que les comparaisons se lisent symétriquement : before.status != after.status.
Condition de transition — une condition qui compare before et after, et cible donc l'instant du changement plutôt qu'un état.
actor — la personne dont l'action a déclenché la règle. actor.id vaut son identifiant et actor.name son nom, ou rien si la règle est partie sans personne derrière (rattrapage automatique, espace client, e-mail reçu, règle planifiée ou « Avant une date »).
analysis — sur une condition d'action seulement, les réponses du modèle d'IA qui a lu le déclencheur : analysis.categorie. Voir Pré-traiter avec l'IA.

Comment faire

Poser un filtre sans écrire d'expression

Dans le bloc « Condition », cliquez sur « Filtre ».
Ajoutez un critère : choisissez le champ, l'opérateur et la valeur.
Ajoutez d'autres critères et combinez-les si nécessaire.

Le filtre est disponible pour les modules CRM, Tâches et Contrats. Pour la facturation et le catalogue, le bouton « Filtre » n'est pas proposé : utilisez une expression.

Pour le CRM et les tâches, une entité doit être choisie avant que le filtre puisse charger ses champs : « Sélectionnez une entité CRM pour configurer le filtre. »

Composer une condition sans écrire de CEL

Dans le bloc « Condition », cliquez sur « Expression (CEL) » puis sur « Assisté ». Sur la vue « Graphique », ouvrez d'abord le bloc « Condition ».
Choisissez « Tous les critères » (tous doivent être vrais) ou « Au moins un critère » (un seul suffit).
Cliquez sur « Ajouter un critère », choisissez un champ puis un prédicat.

Un critère se lit comme une phrase, par exemple « Statut vient de passer à « Gagné » ». Les prédicats disponibles dépendent du champ : « vient de passer à », « a changé », « vient d'être renseigné », « vient d'être vidé », « a augmenté », « a diminué », « est vide », « est renseigné », « existe », « n'existe pas », « est, sans la casse », ou « comparé à un autre champ ».

Une condition vide s'ouvre sur « Assisté ». Une condition déjà enregistrée sous forme d'expression trop riche pour être relue en critères s'ouvre sur « Code ». Le choix entre « Assisté » et « Code » n'est pas enregistré : il ne change que l'affichage.

Sous le capot, ce constructeur produit la même expression (CEL) que si vous l'aviez écrite à la main : les deux formes restent interchangeables tant que l'expression reste assez simple pour être relue en critères. Une expression plus riche affiche « Cette expression est trop riche pour l'éditeur guidé. Elle reste utilisable telle quelle. » : elle continue de fonctionner, mais ne se réédite qu'en écrivant l'expression. Pour un module sans catalogue de champs (Facturation, Catalogue), le message « Les champs de ce module ne sont pas encore catalogués : saisissez le nom technique. » s'affiche à la place du sélecteur de champ.

Écrire une expression

Dans le bloc « Condition », cliquez sur « Expression (CEL) » puis sur « Code ».
Saisissez l'expression dans le champ « Expression ». Elle doit renvoyer vrai ou faux.
Sous le champ, choisissez l'état à lire — « record », « before » ou « after » — puis cliquez sur une variable pour l'insérer.

Exemple : record.status == "won".

Les puces de variables évitent d'avoir à deviner le nom technique d'un champ. Elles sont proposées pour le CRM, les tâches, les contrats et les boîtes mail. Pour la facturation, le catalogue et les stocks, le champ n'affiche pas de puces : reportez-vous à la liste des champs dans Choisir un déclencheur.

Le lien « Documentation CEL » ouvre dans un nouvel onglet la page d'aide interne, avec le tableau des opérateurs et des exemples.

Cibler un changement plutôt qu'un état

Passez la condition en « Expression (CEL) ».
Comparez l'état antérieur et l'état postérieur.

Exemple : before.status != "won" && after.status == "won".

Sans cette comparaison, record.status == "won" reste vraie à chaque enregistrement ultérieur de la fiche : la règle se redéclenche à la moindre modification d'un autre champ.

Exécuter une action selon l'existence d'une tâche ou d'une fiche

Dans le bloc de l'action, ouvrez « Condition (optionnelle) » et cliquez sur « Recherche ».
Dans « Chercher dans », choisissez « Les tâches » ou « Une entité CRM ». Pour une entité CRM, choisissez l'« Entité CRM à interroger ».
Construisez les « Critères de la recherche ». Pour retrouver l'objet qui a déclenché la règle, utilisez les valeurs du déclencheur, par exemple {{trigger.record.id}}.
Dans « L'action s'exécute quand », choisissez « au moins un résultat existe » ou « aucun résultat n'existe ».

Exemple : sur une action « Créer une tâche », la recherche porte sur « Les tâches » liées à la fiche déclencheuse, avec « aucun résultat n'existe ». La tâche n'est créée que si la fiche n'en a pas encore. Sur le schéma, le bloc se lit alors « Aucune tâche ne correspond à la recherche ».

Toutes les recherches d'une règle sont faites une seule fois, avant l'exécution de la première action. Une action qui crée une fiche ou une tâche ne change donc pas le résultat de la recherche d'une action suivante de la même exécution.

Le mode « Recherche » n'est pas proposé sur la règle elle-même, seulement sur ses actions. Une règle au déclencheur « Date » ne peut porter aucune condition, « Recherche » comprise.

Router une action selon l'analyse IA

Sur la règle, ajoutez une analyse IA qui déclare une valeur attendue, par exemple « categorie ». Voir Pré-traiter avec l'IA.
Dans le bloc d'une action, ouvrez « Condition (optionnelle) ».
En mode « Filtre », choisissez le champ « Analyse IA : categorie » ; en mode « Expression (CEL) », écrivez analysis.categorie == "facture".

Pour une valeur de type « Choix », le champ « Analyse IA : clé » propose les options déclarées comme valeurs possibles, avec les opérateurs d'égalité et d'appartenance à une liste. L'action ne s'exécute que si la réponse du modèle satisfait la condition ; les autres actions de la règle sont évaluées chacune selon la même réponse. La condition de la règle elle-même ne peut pas lire l'analyse : elle est tranchée avant que le modèle soit interrogé. Le mode « Recherche » ne la lit pas non plus.

Restreindre une action précise

Dans le bloc de l'action, ouvrez « Condition (optionnelle) ».
Choisissez le mode et saisissez la condition, exactement comme au niveau de la règle.

L'action ne s'exécute que si sa condition est vraie. Les autres actions de la règle ne sont pas affectées.

Référence

Modes disponibles par module

Module	Toujours	Filtre	Expression (CEL)
CRM	Oui	Oui, après le choix de l'entité	Oui, avec les puces de variables
Tâches	Oui	Oui, après le choix du type de tâche	Oui, avec les puces de variables
Contrats	Oui	Oui, sans choix préalable	Oui, avec les puces de variables
Facturation	Oui	Non	Oui, sans puces
Catalogue	Oui	Non	Oui, sans puces
Stocks	Oui	Non	Oui, sans puces
Boîte mail ou webhook	Oui	Oui, après le choix de la source	Oui, avec les puces de variables

Le mode « Recherche » s'ajoute à ces modes sur les conditions d'action, quel que soit le module du déclencheur.

Racines disponibles dans une expression

Racine	Contenu
`record`	L'objet après l'évènement. Ses champs par leur nom technique, plus `record.id`, `record.displayName` et `record.scopeId`
`before`	L'objet avant l'évènement, avec les mêmes noms de champs
`after`	Un alias de `record`
`actor`	La personne dont l'action a déclenché la règle : `actor.id` et `actor.name`
`related.contract`	Pour une règle sur une tâche seulement, le contrat lié à la tâche et ses minutes consommées. Voir Calculer une valeur avec une formule. Expression (CEL) uniquement : le filtre guidé ne le sait pas écrire
`analysis`	Les réponses de l'analyse IA de la règle, par leur clé. Disponible dans la condition d'une action uniquement, jamais dans celle de la règle

Ces racines sont de premier niveau. record.before.statut n'est pas valide : c'est la lecture d'un champ nommé before sur la fiche.

Opérateurs et fonctions

Expression	Effet
`record.status == "won"`	Égalité stricte, les chaînes entre guillemets doubles
`record.status != "lost"`	Différent de
`record.amount > 1000`	Comparaisons numériques : `>`, `>=`, `<`, `<=`
`record.type in ["A", "B"]`	Appartenance à une liste
`record.amount > 1000 && record.status == "won"`	ET logique
`record.status == "won" \|\| record.status == "signed"`	OU logique
`record.email.startsWith("contact@")`	Chaîne commençant par un préfixe, de même `endsWith` et `contains`
`size(record.email) > 0`	Taille d'une chaîne ou d'une liste, pour tester qu'un champ est renseigné
`has(record.email)`	Présence d'une clé, évite l'erreur si le champ est absent du contexte
`lower(record.status) == "client"`	Passage en minuscules, pour une comparaison insensible à la casse
`upper(record.status) == "VIP"`	Passage en majuscules

Prédicats du constructeur guidé

Prédicat	Teste
Vient de passer à	Le champ prend une valeur précise qu'il n'avait pas avant l'évènement
A changé	Le champ a une valeur différente de celle d'avant l'évènement
Vient d'être renseigné	Le champ était vide avant l'évènement et ne l'est plus
Vient d'être vidé	Le champ était renseigné avant l'évènement et est maintenant vide
A augmenté / A diminué	La valeur numérique du champ a augmenté ou diminué
Est vide / Est renseigné	Le champ est vide, ou non, dans l'état actuel
Existe / N'existe pas	Le champ est présent, ou non, dans le contexte de la règle
Est, sans la casse	Égalité avec une valeur, sans tenir compte des majuscules
Comparé à un autre champ	La valeur du champ par rapport à celle d'un autre champ de la même fiche

Conditions de transition

Expression	Effet
`before.status != "won" && after.status == "won"`	La fiche vient de passer à « won ». Ne se redéclenche pas si elle l'était déjà
`before.owner != after.owner`	Le responsable a changé, quelle que soit la nouvelle valeur
`before.amount < after.amount`	Le montant a augmenté
`before.email == null && after.email != null`	Le champ vient d'être renseigné pour la première fois

À la création d'un objet, il n'y a pas d'état antérieur : toutes les valeurs de before sont vides. Une condition de transition ne se déclenche donc pas à la création — utilisez l'évènement « À la création » pour ce cas.

Conditions sur une tâche

Expression	Effet
`after.status == "done"`	La tâche vient de passer à « Terminé », avec « Statut » comme champ surveillé
`before.assignees != after.assignees`	Les responsables ont changé
`after.custom_severite == "haute"`	Un champ personnalisé du type de tâche vaut « haute »
`before.deadline != after.deadline`	L'échéance a été déplacée

Les champs personnalisés d'un type de tâche sont accessibles avec le préfixe custom_. Un champ non renseigné vaut la valeur vide, jamais rien : une condition peut toujours le tester.

Refus à l'enregistrement

Une condition invalide est refusée au moment de l'enregistrement de la règle, et non silencieusement ignorée à l'exécution.

Message	Cause
« Une règle planifiée n'a pas de fiche déclencheuse : retirez sa condition et celles de ses actions. »	La règle a le déclencheur « Date » et porte malgré tout une condition, sur elle-même ou sur une action
« L'expression de la règle d'automatisation est invalide. »	L'expression ne s'analyse pas : parenthèse manquante, opérateur mal écrit
« `<racine>` n'existe pas dans le contexte de la règle. Racines disponibles : record, before, after, related, actor. »	L'expression lit une racine qui n'existe pas
« `<référence>` n'existe pas : record, before, after, related, actor sont des racines de premier niveau. Écrivez `<champ>` sans préfixe. »	Une racine a été imbriquée dans une autre, par exemple `record.before.statut`
« Le champ `<champ>` n'existe pas sur `<entité>`, ou n'est pas accessible aux automatisations. »	Faute de frappe sur un nom de champ, ou champ non exposé aux automatisations

Ces contrôles s'appliquent à la condition de la règle et à celle de chaque action.

Recherche d'une action

Réglage	Choix
« Chercher dans »	« Les tâches » (tous types confondus) ou « Une entité CRM »
« L'action s'exécute quand »	« au moins un résultat existe » ou « aucun résultat n'existe »

Message	Cause
« L'entité de la recherche est requise »	Recherche « Une entité CRM » sans entité choisie
« Le filtre de la recherche est requis »	Aucun critère saisi

La recherche s'exécute avec les droits du système : elle voit toutes les fiches et toutes les tâches de l'organisation, quels que soient les périmètres de la personne qui a déclenché la règle. Une recherche qui ne peut pas s'exécuter — une variable du déclencheur non résolue, un champ inconnu — fait passer cette seule action en « erreur » ; les autres actions sont tentées. Les critères ne peuvent pas utiliser une valeur issue du pré-traitement IA de l'action : les recherches sont faites avant tout pré-traitement.

Une action qui porte une confirmation la demande toujours quand sa condition est une recherche, puisque la réponse n'est connue qu'à l'exécution. Une action dont la recherche donne faux est « ignorée ».

Comportements automatiques

Une condition fausse au niveau de la règle arrête tout : rien n'est exécuté et rien n'est enregistré dans le suivi.
Une condition fausse au niveau d'une action ne fait passer que cette action à « ignorée » ; l'exécution reste « Terminée ».
Une condition qui échoue au moment de son évaluation fait passer l'exécution à « Échec », avec la cause dans la colonne « Erreur ». C'est ce qui distingue une règle cassée d'une règle dont la condition renvoie simplement faux.

Questions fréquentes

Puis-je écrire une condition qui interroge une autre fiche ?

Sur la règle, non : sa condition ne lit que l'objet déclencheur, avant et après. Sur une action, oui, avec le mode « Recherche » : elle teste l'existence de tâches ou de fiches CRM, sans lire leurs valeurs. Les données liées se lisent dans les formules des actions. Voir Calculer une valeur avec une formule.