Déclencheurs automatiques

Un déclencheur crée des demandes sur un service sans que personne ne les saisisse : à une échéance, à la lecture d'une boîte mail, d'un fichier, etc. La demande suit le même chemin qu'une demande saisie : le formulaire du service est rempli (sans être affiché), le processus démarre, et le demandeur est le compte Système, sauf réglage contraire.

Les déclencheurs se règlent dans l'onglet Déclencheurs de la fiche du service (menu Administration › Catalogue et workflow › Catalogue, puis le service). Cet onglet apparaît une fois le service enregistré. Il est ouvert aux Administrateurs et aux Administrateurs Scoop.

Les types de déclencheurs proposés dépendent des modules installés.

Réglages du service

• Commandable dans le catalogue (coché par défaut) : décoché, le service disparaît du catalogue, de la recherche et du catalogue sans compte, et ne peut plus être commandé directement. Seuls ses déclencheurs créent alors des demandes.
• Plafond de demandes par passage (100 par défaut) : quand un passage produirait davantage de demandes, il n'en crée aucune. Il est Bloqué (plafond) et les responsables du service sont alertés. Le plafond protège contre une source qui s'emballe. Exception : une boîte mail ou une échéance est une file qui s'écoule — le passage crée les demandes jusqu'au plafond et laisse le reste au passage suivant.

Enregistrer valide ces deux réglages.

Ajouter un déclencheur

Choisissez le type dans Ajouter un déclencheur, puis Ajouter. La page qui s'ouvre demande :

• un Nom ;
• Actif : un nouveau déclencheur est inactif par défaut. Réglez-le, testez-le avec Aperçu, puis activez-le ;
• le Demandeur des demandes créées : Compte Système, un Utilisateur désigné, ou Désigné par la source (par exemple l'expéditeur d'un mail ; à défaut, le compte Système) ;
• les Réglages du type, propres à chaque type de déclencheur.

La liste des déclencheurs

Pour chaque déclencheur, la liste indique son nom, son type, son état (Actif, Inactif, Passage en cours) et son Dernier passage. Les actions :

• Modifier ;
• Activer ou Désactiver ;
• Lancer maintenant : lance un passage tout de suite (déclencheur actif), puis ouvre son journal ;
• Aperçu (pour les types qui le proposent) : montre ce qu'un passage recevrait, sans rien créer, et prévient si le plafond serait dépassé ;
• Journal ;
• Supprimer : le déclencheur et son journal disparaissent définitivement.

Un type marqué Type indisponible vient d'un module désactivé : le déclencheur reste enregistré mais ne fait plus rien.

Minuterie

Le type Minuterie crée une demande à chaque échéance d'une Planification (cron) à six champs : seconde, minute, heure, jour, mois, jour de la semaine. Par exemple 0 0 8 * * MON : chaque lundi à 8 h. L'heure est celle du fuseau de l'instance, affiché sous le champ.

Chaque demande reçoit trigger_date (2026-10-12), trigger_time (08:00) et trigger_datetime (2026-10-12T08:00:00+02:00) : un champ du formulaire portant ce nom est rempli, sinon la valeur devient une variable de la demande. Désactiver ou supprimer le déclencheur désactive ou supprime sa tâche dans le planificateur. Une échéance passée pendant un arrêt de l'application n'est pas rattrapée.

Quand un passage de la minuterie ne réussit pas, l'historique de sa tâche dans le Planificateur l'explique dans votre langue : éléments refusés (nombre affiché, la tâche est alors réussie en partie), échec du passage, plafond du service dépassé (nombre d'éléments affiché, aucune demande créée), déclencheur supprimé (supprimez la tâche). Le détail de chaque élément est dans Le journal du déclencheur.

Requête planifiée

Le type Requête planifiée exécute une requête du module Requêtes selon une Planification (cron) et crée une demande par ligne du résultat. Choisissez la requête parmi celles que vous pouvez exécuter, puis donnez une valeur fixe à chacun de ses paramètres (@nom). Le passage s'exécute au nom du compte Système.

Chaque colonne renseigne le champ du formulaire de même nom ; sinon elle devient une variable de la demande. Une colonne article.<code> sélectionne un article. Les valeurs arrivent dans un format neutre : dates 2026-11-01, horodatages ISO 8601, nombres à point décimal (1250.50), booléens true/false. Aucune ligne : rien n'est créé. Plus de lignes que le plafond : le passage est bloqué et les responsables sont alertés.

La requête doit écarter les lignes déjà traitées, sinon chaque passage recrée les mêmes demandes. Les valeurs des formulaires soumis sont lisibles dans la vue dynamicforms.v_submitted_field_values ; par exemple, avec un paramètre @service fixé à l'identifiant du service :

SELECT c.code AS contrat, c.ends AS echeance
FROM contracts c
WHERE c.ends < current_date + 30
  AND NOT EXISTS (
      SELECT 1 FROM dynamicforms.v_submitted_field_values v
      WHERE v.catalog_service_id = @service::uuid
        AND v.field_slug = 'contrat'
        AND v.value = c.code)

Avant d'activer le déclencheur, ouvrez l'Aperçu : il exécute la requête et montre, sans rien créer, les lignes qui seraient traitées, ce que devient chaque colonne (champ, article ou variable) et si la demande serait acceptée.

Fichier CSV

Le type Fichier CSV crée une demande par ligne d'un fichier que vous déposez. Dans la liste des déclencheurs, cliquez sur Déposer un fichier, choisissez le fichier, puis Aperçu : vous voyez les lignes lues, ce que devient chaque colonne (champ, article ou variable) et si chaque demande serait acceptée. Rien n'est créé avant Créer les demandes.

La première ligne porte les noms des colonnes. Séparateur ; ou ,, encodage UTF-8 (avec ou sans BOM), 5 Mo au plus ; un champ entre guillemets peut contenir le séparateur ou un retour à la ligne. Chaque colonne renseigne le champ du formulaire de même nom, sinon une variable ; article.<code> sélectionne un article. Plus de lignes que le plafond : rien n'est créé et les responsables sont alertés.

contrat;echeance;article.badge
C-1001;2026-11-01;1
C-1002;2026-11-15;0

Un fichier aperçu mais jamais transformé en demandes est oublié au bout d'un jour. Par l'API : POST …/triggers/{id}/csv/preview puis POST …/triggers/{id}/csv, fichier dans le champ file.

Boîte mail

Le type Boîte mail crée une demande par mail reçu dans une boîte relevée par le module Boîtes mail. Choisissez la boîte dans la liste ; Voir la configuration ouvre sa fiche, Déclarer une boîte en ajoute une. Dans sa configuration, la boîte doit avoir le gestionnaire servicecatalog, et une boîte ne peut alimenter qu'un seul déclencheur.

Chaque mail renseigne les champs from, from_name, to, cc, subject, body, body_html, received_at et message_id (sinon des variables) ; ses pièces jointes vont dans le champ pièce jointe du formulaire, les images insérées dans le texte sont ignorées. Choisissez le demandeur Désigné par la source : l'expéditeur devient le demandeur s'il est un utilisateur connu et actif, sinon c'est le compte Système. Le plafond s'applique à chaque relève de la boîte : au-delà, les mails les plus anciens sont traités d'abord, les autres à la relève suivante.

Une réponse à un mail déjà traité, ou un mail dont le sujet contient le numéro d'une demande entre crochets (par exemple [WF-000123]), ne crée pas de demande : il est ajouté en commentaire à cette demande, avec ses pièces jointes, même si elle est close. Seules les demandes créées par ce déclencheur sont concernées : le numéro d'une autre demande est ignoré, et le mail crée une nouvelle demande.

Attention : l'adresse d'un expéditeur se falsifie facilement. Limitez la boîte aux domaines de confiance avec les filtres d'inclusion du module Boîtes mail. La relève (tâche MailInboxPolling) est désactivée à l'installation : activez-la dans le Planificateur.

Événement

Le type Événement crée une demande quand un événement du produit se produit : un ticket créé ou passé dans un statut, une demande close, un objet de la CMDB modifié… Choisissez l'événement dans la liste ; les valeurs qu'il transporte sont affichées en dessous. Chaque valeur renseigne le champ de même nom, sinon une variable ; les valeurs imbriquées ont des noms à points (par exemple values.cpu).

La condition, facultative, limite les événements retenus : une règle par ligne, de la forme chemin opérateur valeur, toutes devant être vraies. Opérateurs : =, !=, contient (majuscules et accents ignorés), > et < (nombres). Exemple : eventType = StatusChanged.

Un même événement ne crée jamais deux demandes. Le plafond du service s'applique par minute : au-delà, les événements sont ignorés et notés au journal, avec une seule alerte. Une demande qui ne peut pas être créée est notée au journal, sans effet sur l'action d'origine.

Un déclencheur qui écoute les demandes de son propre service (leur création, un changement de statut, leur clôture) ne tourne pas sans fin : comme pour le type Demande d'un autre service, une chaîne s'arrête à la profondeur 5 (variable chain_depth). Le refus est noté au journal et une alerte part aux responsables. La fin d'un passage d'un déclencheur Événement, Seuil franchi ou Demande d'un autre service n'est jamais retenue comme événement.

Seuil franchi

Le type Seuil franchi surveille une valeur numérique transportée par un événement, par exemple la quantité d'un article en stock. Choisissez l'événement, la valeur suivie (quantity), l'opérateur (<, <=, >, >=) et le seuil. L'élément surveillé est le chemin de la valeur qui identifie l'article ou l'alerte (stockItemId) ; vide, c'est le sujet de l'événement.

Une demande est créée quand la valeur franchit le seuil pour un élément, puis plus rien tant qu'elle reste de ce côté : une nouvelle baisse sous le minimum ne crée pas de deuxième demande. Quand la valeur repasse de l'autre côté, le déclencheur se réarme ; le prochain franchissement crée une nouvelle demande. Chaque élément a son propre état. Un événement sans valeur numérique est ignoré.

Demande d'un autre service

Le type Demande d'un autre service enchaîne deux services : quand une demande du service source atteint l'un des statuts métier indiqués (leurs codes, séparés par des virgules), ou se clôt si la case est cochée, une demande de ce service est créée. Elle reprend les valeurs de la demande source (même nom, même champ ; sinon variable), plus source_request_id, source_request_number, source_status et chain_depth.

Avec le demandeur Désigné par la source, la nouvelle demande garde le demandeur de la source s'il est toujours actif, sinon le compte Système. Une demande source ne déclenche qu'une fois pour un même statut, même si elle l'atteint de nouveau. Une chaîne (A crée B, qui crée A…) s'arrête à la profondeur 5 : le refus est noté au journal et une alerte part aux responsables.

Échéance

Le type Échéance crée une demande quelques jours avant, ou après, une date : la fin d'un contrat ou la fin de garantie d'un actif. Choisissez l'échéance, le décalage en jours (-30 = trente jours avant) et l'heure de vérification (planification, comme la minuterie).

Chaque élément concerné donne une seule demande pour une échéance donnée : les vérifications suivantes n'en recréent pas. Si la date change (contrat prolongé), une nouvelle demande est créée le moment venu pour la nouvelle date. Un jour de vérification manqué est rattrapé pendant sept jours. La demande reçoit les valeurs de l'élément, plus due_date et days_before. Plus d'éléments que le plafond : les échéances les plus proches d'abord, les autres à la vérification suivante.

Créer pour une partie des lignes

Dans l'aperçu d'une requête planifiée ou d'un fichier CSV, chaque ligne a une case à cocher. Cochez les lignes voulues (ou Tout cocher), puis cliquez sur Créer pour la sélection : une demande est créée pour chaque ligne cochée, telle qu'elle apparaissait dans l'aperçu. Une ligne refusée par la validation ne peut pas être cochée ; la raison est indiquée dans la colonne Validation. Le plafond s'applique aux lignes cochées. La sélection vaut 15 minutes et ne sert qu'une fois : au-delà, refaites un aperçu. Le journal indique un lancement manuel et qui l'a fait.

Webhook / API

Le type Webhook / API laisse un outil tiers (n8n, Zapier, Make, Power Automate, un outil de supervision, un script) créer une demande par appel. Choisissez le mode d'authentification et la limite d'appels par minute (60 par défaut), enregistrez, puis cliquez sur Générer un nouveau secret. Le secret n'est affiché qu'une fois : copiez-le aussitôt. En générer un autre rend l'ancien inutilisable ; après un changement de mode, générez-en un nouveau.

• Jeton porteur : l'outil envoie l'en-tête Authorization: Bearer <secret> à l'adresse affichée.
• URL secrète : pour un outil qui ne sait pas poser d'en-tête, il appelle l'adresse suivie de /<secret>.
• Signature HMAC : pour un outil qui signe selon Standard Webhooks (en-têtes webhook-id, webhook-timestamp, webhook-signature) ; une signature de plus de 5 minutes est refusée.

L'outil envoie du JSON ou un formulaire encodé (1 Mo au plus). Chaque clé renseigne le champ de même nom, sinon une variable ; un JSON imbriqué donne des noms à points, par exemple ticket.priority ou items.0.name. L'écran donne des exemples curl pour chaque mode.

Réponses : 202 avec le numéro de la demande, 422 si les données sont refusées, 401 mauvais secret, 404 déclencheur inconnu ou désactivé, 413 contenu trop gros, 429 trop d'appels. Si l'outil renvoie le même en-tête Idempotency-Key (ou webhook-id) dans les 24 heures, il reçoit la même réponse et aucune seconde demande n'est créée.

Une intégration qui a déjà un compte peut appeler l'API POST /api/v1/catalog/triggers/<identifiant>/fire avec son jeton, sans secret de déclencheur.

Le journal

Le journal liste les passages, du plus récent au plus ancien : Début, Statut, éléments Reçus, demandes Créées, éléments Refusés. Choisissez un passage pour voir ses éléments : la source de chacun, puis la demande créée ou les erreurs qui l'ont fait refuser.

Statut	Signification
Réussi	Chaque élément a donné sa demande (un passage sans élément est réussi)
Terminé avec refus	Au moins un élément a été refusé (donnée invalide) ; les autres ont donné leur demande
Échec	Erreur technique, par exemple une source injoignable
Bloqué (plafond)	Trop d'éléments : aucune demande créée
Ignoré (passage en cours)	Un autre passage du même déclencheur tournait déjà

Les passages de plus de 90 jours sont supprimés chaque nuit par la tâche planifiée PurgeServiceTriggerRuns, que l'on peut désactiver dans le planificateur.

Alertes

Un passage bloqué par le plafond, un élément refusé ou une erreur technique envoient une seule alerte par passage aux responsables du service (les personnes et les membres des groupes désignés dans l'onglet Général), selon les préférences de notification de chacun. L'alerte renvoie au journal du passage. Une boîte mail ou une échéance qui accumule plus d'éléments que le plafond envoie une alerte de retard, au plus une fois par 24 heures : relevez le plafond ou cherchez l'origine de l'afflux.

Export et import

Un service exporté emporte ses déclencheurs, sans leurs secrets (mots de passe, jetons) ni leur utilisateur désigné. À l'import, ils arrivent désactivés : l'import liste ce qu'il reste à ressaisir avant de les réactiver.

Voir aussi

• « Administrer le catalogue de services » : la fiche d'un service et ses responsables.
• « Superviser les demandes » : les demandes créées par un déclencheur montrent ses données sur leur fiche.