Puis-je appeler un flux Power Automate depuis Heedify ?

Oui. Collez l'URL du déclencheur HTTP Power Automate (Logic App) dans l'URL de l'Action, réglez la méthode sur POST, et placez les champs à envoyer dans le Body à l'aide de tokens $VARIABLE$. Mappez la réponse dans des variables si le flux retourne des données dont vous aurez besoin plus tard.

Quelle validation Heedify applique-t-il à un workflow ?

L'URL de l'Action doit utiliser HTTP ou HTTPS. Le Body doit être un JSON valide (un objet, sans clés dupliquées, pas un tableau). Les valeurs du Mapping et des Headers doivent être des strings.

Workflows

Un workflow est une automatisation réutilisable qui se déclenche sur un événement d’appel, appelle une API HTTP (votre CRM, un ITSM, un flux Power Automate, n’importe quel endpoint HTTPS), et peut stocker des champs de la réponse sous forme de variables que le reste de l’appel pourra réutiliser. Utilisez les workflows pour rechercher un client au moment du décroché, stocker l’identifiant de son enregistrement CRM/ITSM, et renvoyer le résultat de l’appel vers cet enregistrement lorsque l’appel se termine.

Chaque workflow est construit à partir d’une seule Action — un unique appel HTTP avec une méthode, une URL, des en-têtes, un body et un mapping de réponse optionnel.

Vue d’ensemble : récupérer → mapper → stocker → réutiliser

Le schéma qui fait toute la puissance des workflows consiste à rechercher les données tôt et à les réutiliser plus tard :

Récupérer — sur Agent Connected, un workflow appelle l’API de votre CRM/ITSM avec le numéro de l’appelant.
Mapper & stocker — le Mapping extrait l’identifiant de l’enregistrement de la réponse et le stocke sous $CRM_CONTACT_ID$ .
Réutiliser — sur Call Ended, un second workflow renvoie l’issue de l’appel (durée, résumé, lien d’enregistrement) vers ce même enregistrement en utilisant $CRM_CONTACT_ID$ .

Les variables stockées vivent sur l’appel (dans son workflowContext) et persistent entre les déclencheurs, de sorte qu’une valeur capturée à Agent Connected est toujours disponible à Call Ended.

Agent Connected ──► GET  https://crm/contacts?phone=$CALLER_ID_E164$
                     mapping: { CRM_CONTACT_ID: "id" }      ─┐  stores $CRM_CONTACT_ID$
                                                             │
Call Ended ───────► POST https://crm/contacts/$CRM_CONTACT_ID$/calls  ◄─┘  reuses it
                     body: { duration: "$CALL_HANDLE_TIME$", summary: "$CALL_SUMMARY$" }

Créer un workflow

Ouvrez Workflows depuis la barre latérale.
Cliquez sur +Ajouter.
Renseignez les champs et cliquez sur Enregistrer.

Champs

Champ	Description
Nom d’affichage	Nom du workflow. Requis.
Périmètre	L’Entité à laquelle appartient le workflow. Requis.
Événement déclencheur	L’événement d’appel qui déclenche le workflow — l’un des cinq ci-dessous. Requis.
Action → Méthode	Méthode HTTP : GET, POST ou PUT.
Action → URL	L’endpoint API à appeler. Supporte les tokens $VARIABLE$ (ex. `?phone=$CALLER_ID_E164$`).
Action → Headers	Liste clé/valeur d’en-têtes HTTP (ex. `Authorization`). Les valeurs supportent $VARIABLE$ .
Action → Body (JSON)	Objet JSON envoyé avec POST/PUT. Les valeurs supportent $VARIABLE$ . Activable/désactivable.
Action → Mapping	Liste clé/valeur qui stocke des champs de la réponse sous forme de variables — `{ variableName : responseField }`. Activable/désactivable.

Événements déclencheurs

Choisissez un événement par workflow dans la liste fixe affichée dans le portail.

Événement	Moment de déclenchement	Usage typique
Agent Connected	Un agent prend l’appel.	Screen-pop / rechercher le client et stocker son identifiant CRM/ITSM pour plus tard.
Customer Abandoned	L’appelant raccroche pendant l’attente en file.	Journaliser un appel manqué / créer une tâche de rappel.
Call Connected	L’appel est connecté de bout en bout.	Notifier un système externe qu’une conversation a commencé.
Call Ended	L’appel se termine, quelle que soit l’issue.	Renvoyer le résultat de l’appel (durée, résumé, enregistrement) vers le CRM/ITSM.
Agent Declined	Un agent alerté refuse ou laisse sonner (RONA).	Hooks d’alerte / de supervision.

Les recherches relèvent d’Agent Connected (tôt, pour que la valeur soit disponible le reste de l’appel). Les écritures relèvent de Call Ended (tard, lorsque la durée, le résumé et le lien d’enregistrement existent).

Action : appeler une API

L’Action est une seule requête HTTP.

Méthode — GET pour lire, POST/PUT pour envoyer un body. Pour GET, placez les paramètres de requête directement dans l’URL.
URL — l’endpoint HTTPS complet. Chaque $VARIABLE$ est remplacée avant l’envoi de l’appel.
Headers — ajoutez une ligne par en-tête. En-têtes courants :

Header	Exemple de valeur
`Authorization`	`Bearer $env.CRM_TOKEN$`
`Ocp-Apim-Subscription-Key`	$env.APIM_KEY$
`Content-Type`	`application/json`

Body (JSON) — envoyé avec POST/PUT. Doit être un objet JSON valide (sans clés dupliquées, pas un tableau).

Appeler un flux Power Automate

Collez l’URL du déclencheur HTTP request du flux dans URL, réglez Méthode sur POST, et envoyez vos champs dans le Body :

// Action
"method": "POST",
"url": "https://prod-xx.westeurope.logic.azure.com/workflows/.../triggers/manual/paths/invoke?...sig=...",
"headers": { "Content-Type": "application/json" },
"body": {
  "callId": "$callId$",
  "caller": "$CALLER_ID_E164$",
  "agent": "$AGENT_NAME$",
  "summary": "$CALL_SUMMARY$"
}

Si le flux Power Automate répond avec des données, ajoutez un Mapping pour les capturer (voir ci-dessous).

Variables — utiliser les données de l’appel dans l’Action

Partout dans l’URL, les Headers ou le Body, entourez un nom de variable de $...$ et Heedify le remplace par la valeur en direct avant d’envoyer la requête. Les noms sont sensibles à la casse ; un token inconnu est laissé inchangé.

Variables les plus utilisées

Variable	Valeur
$callId$	Identifiant unique de l’appel
$tenantId$	Identifiant du tenant
$CALLER_ID$	Numéro de l’appelant (chiffres, sans `+`) ou identifiant utilisateur Teams
$CALLER_ID_E164$	Numéro de l’appelant au format E.164 (`+33…`) — à utiliser pour les recherches CRM
$AGENT_ID$ / $AGENT_NAME$	Identifiant / nom d’affichage de l’agent connecté
$FLOW_NAME$	Nom du flux d’appel
$QUEUE_NAME$	Première file par laquelle l’appel est passé
$CALL_HANDLE_TIME$	Temps de conversation en secondes (disponible à Call Ended)
$CALL_TERMINATION_REASON$	Comment l’appel s’est terminé (disponible à Call Ended)
$CALL_SUMMARY$	Résumé d’appel par IA (disponible à Call Ended quand la transcription est activée)
$CALL_SENTIMENT$	Sentiment de l’appel : positive / neutral / negative / mixed
$RECORDING_FILE_URL$	Lien vers l’enregistrement (disponible à Call Ended quand l’enregistrement est activé)
$TRANSCRIPT_FILE_URL$	Lien vers la transcription
$env.NAME$	Un secret d’environnement (pour les tokens/clés — ne jamais coder les secrets en dur)

Toutes les variables n’existent pas à chaque instant. Les valeurs de l’appelant, de l’agent, du flux et de la file sont disponibles dès Agent Connected. La durée, le motif de fin, le résumé, le sentiment et les liens d’enregistrement/transcription ne deviennent disponibles qu’à Call Ended (le résumé et la transcription nécessitent l’activation de la transcription/de l’enregistrement sur le flux).

Mapping — stocker la réponse pour plus tard

Un Mapping transforme des champs de la réponse de l’API en variables nommées que vous pouvez réutiliser pour le reste de l’appel. Chaque ligne est :

variableName  ⟶  responseField

Gauche (clé) — le nom de variable que vous inventez. Réutilisez-le plus tard sous la forme $variableName$ . Choisissez des noms qui n’entrent pas en conflit avec les variables intégrées ci-dessus.
Droite (valeur) — le champ à lire dans la réponse JSON.

Exemple — rechercher un client au décroché et stocker l’identifiant de son contact CRM et son niveau :

// Workflow A — Trigger: Agent Connected
"action": {
  "method": "GET",
  "url": "https://crm.example.com/contacts?phone=$CALLER_ID_E164$",
  "headers": { "Authorization": "Bearer $env.CRM_TOKEN$" },
  "mapping": {
    "CRM_CONTACT_ID": "id",
    "CRM_TIER": "tier"
  }
}

Une fois le Workflow A exécuté, $CRM_CONTACT_ID$ et $CRM_TIER$ sont disponibles pour chaque workflow ultérieur du même appel.

Puis renvoyez le résultat lorsque l’appel se termine :

// Workflow B — Trigger: Call Ended
"action": {
  "method": "POST",
  "url": "https://crm.example.com/contacts/$CRM_CONTACT_ID$/activities",
  "headers": { "Authorization": "Bearer $env.CRM_TOKEN$" },
  "body": {
    "type": "phone_call",
    "agent": "$AGENT_NAME$",
    "durationSec": "$CALL_HANDLE_TIME$",
    "outcome": "$CALL_TERMINATION_REASON$",
    "summary": "$CALL_SUMMARY$",
    "recording": "$RECORDING_FILE_URL$"
  }
}

Le même schéma fonctionne pour un ITSM : stockez l’identifiant du ticket à Agent Connected, ajoutez les notes/l’enregistrement de l’appel à ce ticket à Call Ended.

Exemple complet — screen-pop et write-back CRM/ITSM

Étape	Déclencheur	Action	Stocke / utilise
1. Recherche	Agent Connected	`GET …/contacts?phone=$CALLER_ID_E164$`	stocke $CRM_CONTACT_ID$
2. Ouvrir un ticket (optionnel)	Agent Connected	`POST …/tickets` avec `{ "contactId": "$CRM_CONTACT_ID$" }`	stocke $TICKET_ID$
3. Write-back	Call Ended	`POST …/tickets/$TICKET_ID$/notes` avec résumé, durée, enregistrement	utilise $CRM_CONTACT_ID$ , $TICKET_ID$ , $CALL_SUMMARY$

L’ordre compte : un workflow qui stocke une variable doit s’exécuter avant le workflow qui l’utilise. La recherche (étape 1) est sur un déclencheur précoce ; le write-back (étape 3) est sur Call Ended.

Validation

L’URL de l’Action doit utiliser HTTP ou HTTPS.
Le Body doit être un JSON valide — un objet, sans clés dupliquées, pas un tableau.
Les valeurs du Mapping et des Headers doivent être des strings.

Attacher un workflow

Les workflows s’exécutent pour l’Entité (Périmètre) que vous avez sélectionnée, sur le déclencheur que vous avez choisi. Vous pouvez aussi les référencer depuis :

FAQ

Q : Comment stocker des données issues d’un appel API et les réutiliser plus tard ? R : Ajoutez un Mapping à l’Action. Chaque ligne stocke un champ de la réponse sous un nom de variable (ex. CRM_CONTACT_ID = id). Il devient $CRM_CONTACT_ID$ et reste disponible pour le reste de l’appel, y compris dans les workflows ultérieurs sur des déclencheurs ultérieurs.

Q : Un workflow peut-il envoyer des en-têtes HTTP personnalisés ? R : Oui — la liste clé/valeur Headers. Utilisez-la pour Authorization, Ocp-Apim-Subscription-Key, serviceApiKey, Content-Type, etc. Les valeurs supportent $VARIABLE$ , vous pouvez donc injecter des secrets avec $env.NAME$ .

Q : Puis-je appeler un flux Power Automate ? R : Oui. Collez l’URL du déclencheur HTTP du flux dans l’URL de l’Action, réglez la méthode sur POST, et envoyez les champs dans le Body avec des tokens $VARIABLE$ . Mappez la réponse si le flux retourne des données dont vous aurez besoin plus tard.

Q : Quels événements déclenchent un workflow ? R : Cinq événements fixes : Agent Connected, Customer Abandoned, Call Connected, Call Ended, Agent Declined. Chaque workflow en écoute exactement un.

Q : Quelle validation Heedify applique-t-il ? R : L’URL de l’Action doit être en HTTP/HTTPS. Le Body doit être un JSON valide (objet, sans clés dupliquées). Les valeurs du Mapping et des Headers doivent être des strings.

Works with : Microsoft Teams, Teams Phone, APIs HTTPS, Power Automate, CRMs et ITSMs basés sur webhook, Variables, Flux d’appel, Files d’attente.