> For the complete documentation index, see [llms.txt](https://doc.dastra.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.dastra.eu/features/settings/workflow-rules.md). # Règles de workflows Intégrez des processus complexe à l'aide des Règles de workflow personnalisées {% hint style="info" %} **Étapes de processus vs règles de workflow** Les [étapes de processus](/features/settings/etapes-de-processus.md) définissent les statuts que traversent les objets (ex. Nouveau → En cours → Fait). Les **règles de workflow** automatisent des actions lorsque ces étapes ou d'autres événements surviennent. Les deux fonctionnalités sont complémentaires. {% endhint %} ## Le principe de fonctionnement Les Règles de workflow dans Dastra sont un ensemble d'actions (notifications par e-mail, planification d'un audit, tâches et mises à jour de champs) qui sont exécutées lorsque certaines conditions sont réunies. Ces règles automatisent le processus d'envoi des notifications par e-mail, d'attribution des tâches et de mise à jour de certains champs d'un enregistrement lorsqu'une règle est déclenchée. ![Schéma du principe de base](https://1301193153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LvBxs22wUMicv9uWp6C-2584506019%2Fuploads%2Fd4Hwv9Zzs8N8Iwlqhl1E%2Fimage.png?alt=media\&token=f13867b5-098b-4648-854a-baf58f7a1f20) {% hint style="info" %} Le nombre de règles de workflow disponibles dépend de votre plan, de **25 à 100 règles**. Une capacité supplémentaire peut être achetée si nécessaire. Contactez votre account manager pour plus de détails. {% endhint %} ## Comment créer une règle de workflow dans Dastra ? * Allez dans [la page de configuration des règles de workflows votre espace de travail](https://app.dastra.eu/workspace/0/settings/workflow-rules) * Cliquez sur "Nouvelle règle de workflow" * Choisissez un nom et le type d'entité concernée (Traitement, Violations...) * Vous arrivez dans le designer de règles ### Définition du déclencheur Vous pouvez déclencher une règle de workflow sur deux évènements : * Lors d'**une action sur une entité concernée** : création, modification, changement d'étape ou mise à la corbeille (seulement pour les objets pour lesquels la corbeille existe)

* **Contrôle de date récurrent** — la règle est évaluée chaque jour à une heure configurée et se déclenche en fonction d'un champ date de l'objet. Configurez les paramètres suivants : * **Exécuter tous les jours à** — l'heure du contrôle quotidien (avec gestion du fuseau horaire, ex. 00:00 Europe/Paris). * **Champ date à vérifier** — le champ date à évaluer (ex. date de clôture, date de création, date de révision…). * **Condition sur la date** — choisissez parmi : * **A été dépassée** — se déclenche le jour où la date est atteinte. * **Modificateurs de date** — ajoutez un décalage par rapport à la date : * **Surviendra dans** — se déclenche N heures / jours / mois / ans *avant* la date (ex. 30 jours avant l'expiration d'un contrat). * **A été dépassée depuis** — se déclenche N heures / jours / mois / ans *après* la date (ex. 1 jour après la clôture). Le bouton **"Voir les éléments comme si c'était aujourd'hui"** permet de prévisualiser les objets qui correspondraient actuellement à la règle, utile pour tester avant activation.

Un seul déclencheur (ou trigger) peut être défini par règle de workflow. A noter que vous pouvez choisir si le workflow peut s'exécuter plus d'une fois par entité. **Il est fortement recommandé** **d'exécuter les workflows une seule fois par entité**, car l'exécution d'un workflow plusieurs fois peut conduire assez facilement à des problèmes de répétition de création de tâches ou de doublons de notifications. ### Définition de conditions Vous pouvez configurer une ou plusieurs conditions d'exécution par règle. Les conditions peuvent s'appliquer à l'ensemble des champs de l'objet et peuvent être assemblées au sein de groupes pour vous permettre de mettre en place l'ensemble des scénarios possibles (avec la possibilité de changer l'association "Et" ou "Ou").

Ici l'action sera lancée si l'étape est "validation de l'identité" ou "nouveau" ET que la date de validation de l'email est remplie

### Définition des actions Pour ajouter une nouvelle action, cliquez sur le bouton "**Ajouter un action**" et choisissez le modèle que vous souhaitez mettre en place Voici les **différents types d'actions** que vous pouvez déclencher : * Envoi d'une notification par email * Mise à jour d'un champ de l'entité concernée * Ajout d'un tag à l'entité * Planification automatique d'une réponse à un questionnaire * Définition de la personne assignée * Création automatique d'une tâche * Envoi d'une notification dans un canal Microsoft Teams (si l'intégration Microsoft Teams est installée) * Envoi d'une requête HTTP vers une plateforme externe (si l'intégration HTTP / Custom API est activée) Pour les demandes d'exercices de droit, des actions supplémentaires sont disponibles : * Clôturer la demande * Mise à la corbeille de la demande * Anonymisation de la demande (uniquement possible si la demande est clôturée) Il est possible de chaîner les conditions. Vous pouvez ajouter plusieurs actions par condition en cliquant de nouveau sur "ajouter une action", jusqu'à un maximum de **20 actions par règle**. Au-delà, le bouton d'ajout se désactive et un message indique que le maximum est atteint.

Règle de workflow comportant jusqu'à 20 actions — Une règle peut comporter jusqu'à 20 actions

{% hint style="info" %} Exemple : envoyer une notification à plusieurs personnes lors de la création d'une tâche. Pour cela, sélectionner le déclencheur "taches" et selon les conditions de la tache (par exemple, l'ajout d'un tag), ajouter une action "notification" {% endhint %} ### Unité organisationnelle d'une tâche créée L'action **« Ajouter une tâche »** comporte un champ **Unité organisationnelle** qui détermine l'unité de rattachement de la tâche créée : * **Par défaut (hérité de l'objet)** : la tâche est rattachée à l'unité organisationnelle de l'objet déclencheur, s'il en a une. C'est la valeur appliquée lorsque le champ reste vide. * **Une unité précise** : sélectionnez une unité dans l'arborescence ; la tâche est rattachée à cette unité, quelle que soit l'unité de l'objet déclencheur. Pour les règles portant sur les objets des référentiels (**Actif**, **Données**, **Mesure de sécurité**, **Acteur**, **Catégorie de personne concernée**), qui n'ont pas d'unité organisationnelle, le champ est obligatoire.

Action Ajouter une tâche avec le champ Unité organisationnelle renseigné — Choix de l'unité organisationnelle de la tâche créée par la règle

### Personne assignée et propriétaire d'une tâche créée L'action **« Ajouter une tâche »** comporte les champs **Assignée à** et **Propriétaire**. Chacun accepte une variable de l'objet déclencheur (son créateur, son propriétaire, son responsable, etc.) ou un utilisateur nommé. Si la variable n'est pas renseignée sur l'objet, la tâche est tout de même créée. La variable **Responsable de l'UO** confie la tâche au responsable de l'unité organisationnelle de l'objet déclencheur. Si cette unité n'a pas de responsable, celui de l'unité parente la plus proche est retenu. Si l'objet n'a pas d'unité organisationnelle, l'action utilise l'**Unité organisationnelle par défaut** sélectionnée dans l'action, avec la même règle. Si aucun responsable n'est trouvé, la tâche est créée sans assigné, sans bloquer la règle. ### Lier un modèle de message à une action Pour les règles liées aux **demandes d'exercice de droits**, l'action **« Envoyer un message au demandeur »** peut s'appuyer sur un **modèle de message** existant plutôt que sur un contenu saisi manuellement.

Action Envoyer un message au demandeur avec le bouton Sélectionner un modèle — L'action « Envoyer un message au demandeur » propose « Sélectionner un modèle »

Dans l'action, cliquez sur **« Sélectionner un modèle »**, puis choisissez un modèle de type **« Message de demande »** de votre espace de travail. Au déclenchement de la règle, le contenu du modèle est récupéré et les variables personnalisées (par exemple `{{ givenName }}`, `{{ refId }}`) sont substituées automatiquement.

Fenêtre de sélection d'un modèle de message — Choix d'un modèle « Message de demande » de l'espace de travail

* Le message envoyé utilise toujours la version à jour du modèle, même si celui-ci est modifié après la création de la règle. * Si le modèle lié est supprimé, l'exécution échoue explicitement : le message n'est pas envoyé silencieusement. * Les règles utilisant un contenu manuel ne sont pas affectées. Vous pouvez repasser d'un modèle lié à un contenu manuel à tout moment en cliquant sur **« Retirer »**.

Action avec un modèle de message lié et les boutons Changer de modèle et Retirer — Une fois lié, le modèle peut être changé ou retiré ; les variables sont substituées à l'exécution

### Envoyer une notification Teams Lorsque l'[intégration Microsoft Teams](/features/integrations/microsoft-teams.md) est installée et activée sur l'espace de travail, l'action **« Envoyer une notification Teams »** publie une carte dans le canal Teams relié au webhook. Il n'y a pas de destinataire à choisir. Renseignez les champs suivants : * **Titre de la carte** (obligatoire, 150 caractères au maximum). * **Message** : texte riche affiché dans la carte. * **Inclure un lien vers l'objet dans la carte** : ajoute à la carte un lien direct vers l'objet déclencheur dans Dastra. L'option est activée par défaut. Le titre et le message acceptent les variables personnalisées de l'objet déclencheur : tapez `{{` pour afficher la liste des variables disponibles (voir [Variables personnalisées](#variables-personnalisees)). {% hint style="info" %} L'action n'apparaît dans la liste des actions que si l'intégration Microsoft Teams est installée et activée. Si l'intégration est désinstallée ou désactivée, le formulaire de l'action affiche un avertissement : l'action échoue tant que l'intégration n'est pas configurée. {% endhint %} ### Envoyer une requête HTTP L'action **« Envoyer une requête HTTP »** appelle l'API d'une plateforme externe au déclenchement de la règle : outil de ticketing, ITSM, service interne, hub d'automatisation. Elle sert lorsqu'aucun connecteur natif n'existe pour votre outil. **Prérequis** : l'intégration [HTTP / Custom API](/features/integrations/custom-http.md) est activée dans **Paramètres > Intégrations**, avec une connexion pour la plateforme cible (clé d'API, identifiants Basic ou OAuth 2.0). Ajouter ou modifier cette action demande la permission **Intégrations** sur l'espace de travail. Renseignez les champs suivants : * **Méthode** (GET, POST, PUT, PATCH ou DELETE) et **URL** absolue (`https://…`). L'hôte est fixe ; le chemin et les paramètres peuvent contenir des variables. * Onglet **Authentification** : la connexion à utiliser, ou **Sans authentification** pour un point d'accès public. Les identifiants restent sur la connexion, jamais dans la règle. * Onglet **En-têtes** : jusqu'à 20 en-têtes, dont les valeurs acceptent des variables. * Onglet **Corps** (POST, PUT et PATCH) : un corps **JSON** ou **XML** rédigé comme un modèle. Tapez `{{` dans l'URL, un en-tête ou le corps pour insérer les champs de l'objet déclencheur (voir [Variables personnalisées](#variables-personnalisees)). Le corps rendu doit être un JSON ou un XML bien formé, sinon rien n'est envoyé et l'exécution est journalisée en erreur. * **Tester la requête** rend la requête avec un objet réel de l'espace de travail. **Aperçu** n'envoie rien ; **Envoyer la requête** fait l'appel réel et affiche la réponse de la cible. * **Générer avec l'IA** rédige la requête à partir d'une consigne et du payload attendu par la cible. Seuls les noms et types des champs sont transmis à l'assistant, jamais vos données ni vos identifiants.

Action Envoyer une requête HTTP dans une règle de workflow — L'action « Envoyer une requête HTTP »

{% hint style="warning" %} Désactiver ou désinstaller l'intégration HTTP / Custom API, ou supprimer une connexion, désactive automatiquement les règles qui en dépendent. Réactivez-les une fois la dépendance rétablie. Chaque envoi est tracé dans les journaux de l'intégration. {% endhint %} ### Variables personnalisées \ **Exemple** Pour afficher une variable de type chaine de caractère (la référence d'un traitement) Très souvent, dans les notifications personnalisées par exemple, il sera intéressant d'y injecter des informations provenant de l'objet qui est entré dans le workflow : le nom du traitement, sa date de publication... sont autant de variables que vous pourrez facilement injecter dans le texte de vos notifications grâce au système d'injection de variables. En interne, Dastra utilise un moteur de templating basé sur [LiquidJS](https://shopify.github.io/liquid/basics/introduction/) **Pour accéder aux différentes variables de l'objet du trigger, tapez "{{",** cela affichera une liste de propositions de variables que vous pouvez injecter dans le contenu ``` {{ref}} ``` Pour afficher toutes les valeurs d'une variable de type tableau (les tags) ``` {% for tag in tags %} {{ tag.label }} {% endfor %} ``` Pour afficher uniquement la 1ere valeur d'une variable de type tableau : (1er approbateur d'un traitement) ``` {% assign accountable = accountables | first %} {{accountable.displayName}} ``` ### Exemples **Exemple de workflow basé sur une action** Cet exemple permet de voir l'utilisation d'un workflow par action permettant de notifier les approbateurs d'un traitement lors d'un changement d'étape si l'étape courante est différente de "Nouveau"

**Exemple de workflow "complexe" basé sur une date :** Cet exemple permet de voir l'utilisation d'un workflow par date permettant de nettoyer automatiquement les demandes de droits dont l'identité de l'utilisateur n'aurait pas été validé un mois après la création.

**Tous les jours, fermer et anonymiser les demandes de droit dont l'identité du demandeur n'a pas été validée un mois après la création**

### Bibliothèque de modèles de règles La bibliothèque de modèles de règles de workflow regroupe deux sources : * **La bibliothèque par défaut de Dastra** — des règles prêtes à l'emploi couvrant les scénarios d'automatisation les plus courants : gestion des violations de données, expiration de contrats, révision des fournisseurs, cycle de vie des demandes d'exercice de droits… Maintenue et enrichie par Dastra. * **Les modèles personnalisés de votre organisation** — toute règle que votre équipe a enregistrée comme modèle. Ces modèles sont accessibles dans la même bibliothèque et réutilisables par tous les utilisateurs de l'espace de travail. Les modèles peuvent être filtrés par type d'objet et par langue. **Créer une règle depuis un modèle** Lors de la création d'une nouvelle règle, choisissez **"Depuis un modèle"** pour démarrer depuis une configuration préétablie plutôt que depuis une page blanche.

Dialogue de création de règle — Depuis zéro ou Depuis un modèle — Choisir de créer une règle depuis un modèle existant

Bibliothèque de modèles de règles avec le modèle DSR assign from tags — Sélection du modèle souhaité dans la bibliothèque

**Enregistrer une règle comme modèle** Ouvrez une règle de workflow existante et cliquez sur **"Enregistrer comme modèle"**. Donnez-lui un nom, une description, puis confirmez. Le modèle est immédiatement disponible dans la bibliothèque, réutilisable par tous les utilisateurs de l'espace de travail.

Dialogue Enregistrer comme modèle avec nom et description — Enregistrement d'une règle de workflow comme modèle réutilisable

Cette fonctionnalité permet d'harmoniser les règles d'automatisation à l'échelle de l'organisation et d'éviter de reconstruire des workflows identiques sur chaque objet ou entité. *** ## Tutoriel vidéo : les règles de workflow {% embed url="" %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://doc.dastra.eu/features/settings/workflow-rules.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.