Documentation / Agent d'opérations
Agent d'opérations : déclencheurs
Ce qui lance une exécution (appel du standard terminé, webhook, planning, autre agent, exécution manuelle) et comment capturer un événement réel avec Écouter.
Dernière mise à jour:
Un déclencheur est la première boîte du tableau : il décide quand le flux s'exécute et avec quelles données il démarre. Chaque type de déclencheur peut figurer une seule fois sur un tableau, et un tableau peut en contenir plusieurs types (par exemple un appel du standard et une exécution manuelle). Les déclencheurs ne lancent des exécutions que lorsque l'agent est activé ; une exécution de test depuis le concepteur fonctionne dans tous les cas.
Appel terminé (standard)#
Chaque appel journalisé par le standard du projet lance le flux. Le standard est connecté une seule fois pour tout le projet sous Intégrations (voir Contacts et intégration du standard). Le déclencheur fournit aux étapes :
caller_number,caller_name,callee_number,callee_name,direction(entrant, sortant, interne)duration_sec,status(répondu, manqué, etc.),subject,extension(le nom de l'utilisateur du poste)recording_url(le lien de téléchargement du standard) etrecording_ref(le nom de fichier de l'enregistrement)call_id,contact_id,contact_number
Un appel manqué n'a pas d'enregistrement. Les étapes qui en ont besoin (téléchargement, transcription, résumé, rapport) se marquent Ignorée : rien à faire et l'exécution se termine quand même, de sorte qu'un appel manqué ne laisse jamais une exécution en attente de nouvelles tentatives.
Gardez recording_url à l'intérieur du flux : il contient le secret de téléchargement du standard. Pour identifier un enregistrement dans un autre système, envoyez plutôt recording_ref.
Un appel du standard peut lancer plusieurs agents : chaque agent actif avec ce déclencheur s'exécute sur cet appel.
Webhook reçu#
Tout ce qui peut envoyer du JSON peut lancer l'agent : le tableau affiche l'URL propre de l'agent dans l'inspecteur (également sous Réglages). Le corps de la requête devient les données du déclencheur, ainsi un champ order_id dans le corps devient {{trigger.order_id}} dans les étapes.
S'exécute selon un planning#
Lance le flux toutes les heures, chaque jour à 09:00, les jours ouvrés à 09:00, chaque lundi à 09:00, le premier du mois à 09:00, ou selon votre propre expression cron, dans le fuseau horaire de votre choix, au plus une fois toutes les cinq minutes. Deux choix :
- Si l'exécution précédente est encore en cours : ignorer celle-ci, ou la mettre en file.
- Déclenchements manqués pendant une indisponibilité du service : les ignorer, ou exécuter une fois.
Après l'enregistrement, le concepteur affiche l'estimation des exécutions et du coût par mois, car chaque exécution facture au moins 30 secondes d'automatisation. La Vue d'ensemble affiche la prochaine exécution planifiée. Le déclencheur fournit scheduled_for, fired_at, cron, timezone et missed_by_s.
Appelé par un autre agent#
Un autre agent d'opérations du projet transmet des données à celui-ci, avec Appeler un autre agent ou le Répartiteur. Les données envoyées sont les données du déclencheur ; caller_agent et caller_run_id indiquent qui a appelé. Utilisez-le pour des agents qui font un seul travail pour plusieurs autres.
Exécution manuelle#
Lance le flux depuis la console ou l'API avec des données que vous saisissez. Utile pour les tableaux que vous exécutez à la demande, par exemple pour transcrire un enregistrement à partir de son URL.
Écouter l'événement réel#
Les déclencheurs Webhook reçu, Appel terminé (standard) et Appelé par un autre agent ont un bouton Écouter dans l'inspecteur. Appuyez dessus, puis provoquez l'événement : envoyez le webhook depuis l'autre système, passez puis raccrochez un appel sur le standard, ou exécutez le tableau qui appelle celui-ci. L'événement suivant s'affiche dans l'inspecteur exactement tel que le déclencheur le recevrait, mis en forme, et il n'est pas exécuté, même si l'agent est désactivé. L'écoute dure dix minutes. Appuyez sur Utiliser comme données de test pour exécuter le tableau avec exactement ces données.
C'est le moyen le plus rapide de connaître les vrais noms de champs qu'un système envoie, au lieu de les deviner.