Automatisations : présentation

Déclencheur, filtre, file d’attente, puis étapes. Un essai annule toutes les écritures. Dix échecs d’affilée désactivent le flux.

3 min de lectureMis à jour le 5 octobre 2026Source : docs.frappe.io

Rôle

Un Automation Flow dit : quand ceci arrive à ce type d’enregistrement, faire ces choses dans l’ordre, sans code. On choisit un déclencheur, on resserre par des conditions, on ajoute des étapes : champ, notification, affectation, webhook, attente, branchement. La configuration décrite est stable. Le journal d’exécution et les internes peuvent changer : la fonction est en bêta.

Les outils à usage unique restent préférables quand ils suffisent : une notification pour un e-mail ou un message système, un webhook pour poster vers une URL, une Assignment Rule pour répartir, un script serveur pour changer le comportement en code.

Le flux sert quand il faut plusieurs étapes, une attente, une branche (au-dessus de 10 000 ou non), ou un document lié : le déclencheur est une Communication, l’enregistrement à modifier est le Lead.

Déroulement

Déclencheur : événement, date, planification, événement d’application ou lancement manuel. Détail dans Déclencheurs et conditions.
Correspondance : champs et condition.
File : le déclencheur qui correspond est mis en file, pas exécuté dans la requête. Un worker le prend peu après le commit, pour qu’un webhook lent ne bloque pas l’enregistrement. Plusieurs enregistrements du même document avant le passage du worker n’en font qu’une exécution.
Exécution : les étapes dans l’ordre, et un Automation Run par étape. Détail dans Étapes et actions.

Le planificateur et les workers doivent tourner. Seul un System Manager crée, modifie ou lit les flux.

Créer

AwesomeBar, Automation Flow, New. Title, Document Type, Trigger Type et ses champs. Match Fields et Advanced Expression using Python, facultatifs. Au moins une ligne sous Actions. Save, Test Run sur un vrai document : toutes les modifications sont annulées. Puis Enabled, et enregistrer encore. Sans action, on ne peut pas activer.

Exemple, Lead, Doc Created, Annual Revenue supérieur à 1 000 000. Actions : Assign to User [email protected], e-mail au même sujet New lead: {{ doc.lead_name }}, Wait 2 Days, puis e-mail à @assignees, sujet Follow up on {{ doc.lead_name }}, à condition que doc.status == "Lead".

Historique

Chaque Automation Run est lié au flux et au document.

Statut	Sens
Success	Chaque étape a réussi ou a été sautée
Partially Failed	Une étape a échoué et Stop on Error était coupé : la suite a tourné
Failed	Échec avec Stop on Error, ou le run n’a pas pu démarrer
Waiting	Pause sur un Wait, reprise seule
Skipped	Document supprimé, ou plus de correspondance si Revalidate on Run

Le détail montre statut, sortie, durée, et pour un échec le message et la pile. Une étape sautée montre la condition et les valeurs lues. Les journaux partent au bout de 30 jours, avec le nettoyage standard.

Réglages du site

Automation Settings :

Disable Automations arrête l’envoi. Les lignes déjà en file ne sont pas touchées. Pour couper même si la base est injoignable : "automation_disabled": 1 dans site_config.json.
Maximum Recursion Depth, 3 par défaut : nombre de fois où les actions d’un flux peuvent en déclencher un autre avant refus.
Failure Threshold, 10 par défaut : après autant d’échecs consécutifs, le flux est désactivé, ses runs en attente sont sautés, le propriétaire est prévenu. La raison est dans Disabled Reason.
Allow Unregistered Events accepte un événement qu’aucune application installée n’a enregistré. Voir Étendre les automatisations.

Le reste (vidange, reprises, rétention, tailles) règle le worker et change rarement.

Point d’attention

Test Run annule tout. Enabled exige au moins une action. Disable Automations ne retire pas ce qui est déjà en file.