Traitement des réponses par e-mail

Q: Email-to-Case est-il obligatoire ?

Il faut une infrastructure de réception qui crée des EmailMessage entrants. Email-to-Case est une possibilité ; un gestionnaire de service de messagerie personnalisé peut aussi convenir. Un relais de messagerie seul ne garantit pas la création de ces enregistrements : vérifiez un message reçu réel.

Q: Peut-on transmettre le texte de la réponse à l’agent ?

Oui. Le champ Traitement par IA active ce traitement. Le corps de la réponse devient un message pour l’agent et peut poursuivre la conversation associée à l’action.

Suivi des réponses Lorsqu’un destinataire répond à un e-mail envoyé par un agent, REDA AI peut rapprocher cette réponse d’actions en attente et poursuivre le traitement : exécuter une action préparée ou transmettre le texte à l’agent. Ce mécanisme permet des échanges en plusieurs étapes. Les correspondances de fil et d’objet doivent être configurées et testées ; elles ne vérifient pas à elles seules l’identité de l’expéditeur.

Ce que couvre cette page

Cette page décrit la réception des réponses aux e-mails initiés par l’agent. Elle complète deux fonctions :

Canal e-mail — Envoi : envoi du message initial et association aux actions suivies avec une clé group_key.
Actions planifiées : stockage et exécution des actions de suivi, notamment celles déclenchées par une réponse.

Ce mécanisme est distinct du canal e-mail — Réception, qui transmet les messages et documents reçus à une adresse de service de messagerie à un agent dans une nouvelle conversation.

Détecter les réponses

REDA AI expose l’action Apex invocable Process Inbound Emails, qui examine les nouveaux enregistrements EmailMessage pour rechercher les réponses correspondant à des actions suivies. Configurez un Flow déclenché par un enregistrement EmailMessage pour l’appeler.

Envoi suivi par l’agent
Après la création des actions en attente, l’agent appelle send_email avec la même clé group_key. La plateforme inscrit l’identifiant EmailMessage retrouvé et l’objet du message sur les actions du groupe qui ne suivent pas encore de message. Consultez Canal e-mail — Envoi.
Réception des réponses
Les réponses arrivent par l’infrastructure de réception Salesforce configurée, souvent Email-to-Case. Le mécanisme a besoin d’un enregistrement EmailMessage avec Incoming = true pour chaque réponse à traiter.
Déclenchement du Flow
Un Flow créé dans votre organisation, déclenché après la création d’un EmailMessage entrant, transmet son identifiant à Process Inbound Emails.
Vérification des actions en attente
Après la lecture des messages et la vérification de l’activation, le gestionnaire recherche des actions en attente de réponse. S’il n’en trouve aucune, il s’arrête sans lancer de traitement asynchrone.
Rapprochement asynchrone
Lorsque des actions existent, le gestionnaire place les identifiants des messages dans un traitement Queueable chargé de rechercher les correspondances.
Stratégies de correspondance
Le traitement compare d’abord le parent commun des messages, puis ajoute les correspondances d’objet normalisé, après retrait de préfixes tels que « Re: » et « Fwd: ». La recherche par objet peut ajouter des actions même si un parent a déjà correspondu.
Traitement de l’action
Pour chaque action correspondante, le traitement vérifie ses conditions, puis transmet la réponse à l’agent si l’analyse IA est configurée, ou exécute directement son contenu préparé, par exemple un e-mail ou une mise à jour. Son état est ensuite mis à jour selon le résultat.

Mise en place

Étape 0 — Activer le suivi des réponses

Le suivi des réponses est désactivé par défaut. Activez le paramètre correspondant dans l’administration REDA AI, sous la configuration système et les notifications. Lorsque ce contrôle est désactivé, le gestionnaire ne lance pas le rapprochement, même si le Flow et les agents sont configurés. Cette désactivation normale ne produit ni erreur ni incident explicatif.

Vérifiez également la configuration Salesforce d’Enhanced Email et de la réception : le suivi utilise les enregistrements EmailMessage effectivement créés. Activer Enhanced Email seul ne configure pas la réception des réponses.

Étape 1 — Vérifier la création des EmailMessage entrants

Les réponses doivent être enregistrées comme EmailMessage entrants. Email-to-Case est une possibilité ; un service de messagerie personnalisé peut aussi créer ces EmailMessage. Vérifiez le résultat réel de votre configuration : un relais d’envoi ou une adresse seule ne garantit pas cette création.

Les requêtes sur EmailMessage sont dynamiques afin d’éviter une dépendance de compilation à l’infrastructure de réception. Sans objet disponible ou message entrant accessible, le suivi ne peut pas fonctionner.

Étape 2 — Créer le Flow déclenché par un enregistrement

Objet : EmailMessage
Configurez le Flow sur EmailMessage, après la création d’un enregistrement.
Critère d’entrée : Incoming = TRUE
Limitez les critères d’entrée aux e-mails entrants. Les messages sortants n’ont pas à être traités ici.
Facultatif : filtres supplémentaires
Ajoutez les critères utiles à votre cas d’usage : certaines requêtes, boîtes de réception ou autres conditions métier. Réduisez les appels inutiles, en particulier pour les volumes importants.
Ajouter l’action Apex
Transmettez l’identifiant de l’enregistrement déclencheur à l’action. L’invocable reçoit une liste d’identifiants EmailMessage et peut traiter les entrées regroupées par Flow ; configurez l’entrée selon la présentation de l’action dans votre version de Flow Builder.
Activer
Enregistrez et activez le Flow. Les messages entrants qui satisfont ses critères sont désormais proposés au rapprochement.

Étape 3 — Configurer les actions en attente de réponse

Le Flow ne peut rapprocher les réponses que s’il existe des actions en attente. Demandez à l’agent de créer les actions schedule_action appropriées avec un déclenchement sur réponse, puis d’envoyer l’e-mail avec la même clé group_key. Consultez Actions planifiées pour le contrat de l’outil.

Étape 4 — Diriger les réponses vers cette réception

Le traitement ne démarre qu’après l’arrivée effective de la réponse dans Salesforce. Son adresse de destination dépend du message auquel le client de messagerie répond. L’agent peut définir une adresse de réponse : choisissez la boîte reliée à la réception de l’étape 1. Une boîte non surveillée empêche ce mécanisme de voir les réponses, même si le Flow est correct.

Les instructions de l’agent guident le choix de cette adresse ; consultez Choisir l’expéditeur et l’adresse de réponse. Une adresse non reconnue peut être signalée tout en restant appliquée. Vérifiez donc un aller-retour réel et les avertissements d’envoi.

Depuis la version 1.14, l’agent peut préciser une adresse de réponse. Auparavant, les réponses suivaient l’adresse d’expédition. Ce paramètre permet de les diriger vers votre infrastructure de réception.

Deux stratégies de correspondance

Le traitement utilise les deux stratégies suivantes et déduplique les actions déjà retenues dans le même lot :

Stratégie	Rapprochement	Limites
Parent commun	Le `ParentId` de la réponse correspond au ParentId du message sortant suivi. La comparaison porte sur le parent commun des deux EmailMessage, et non sur l’égalité entre le parent entrant et l’identifiant du message sortant.	Dépend de la façon dont votre infrastructure renseigne le parent. Plusieurs messages liés au même parent peuvent correspondre ; vérifiez ce comportement avec votre configuration.
Objet normalisé	L’objet entrant, après retrait de préfixes tels que Re: et Fwd:, est comparé sans tenir compte de la casse à l’objet suivi, normalisé de la même manière.	Permet une correspondance sans parent et peut aussi ajouter des actions lorsque le parent a déjà produit un résultat.

Un même objet réutilisé peut donc activer plusieurs actions. Le parent ne garantit pas la désambiguïsation des résultats supplémentaires par objet, et le rapprochement ne filtre pas sur l’adresse de l’expéditeur. Utilisez des objets distinctifs et des contrôles d’entrée adaptés.

Après une correspondance

Le champ Traitement par IA de l’action détermine la suite :

Traitement par IA = true — le corps de la réponse est transmis à l’agent pour un nouvel échange. Avec une conversation associée valide, il peut poursuivre son historique et préparer la suite, notamment un nouveau suivi par e-mail.
Traitement par IA = false — le contenu préparé de l’action est exécuté directement. Ce mode convient aux opérations fixes : message de remerciement, modification d’état ou notification interne.

Une action traitée avec succès quitte l’état d’attente et n’est plus sélectionnée comme telle. Une erreur récupérable peut toutefois la remettre en attente pour une nouvelle tentative ; ne confondez pas la réception d’une réponse avec la réussite de l’action.

Les conditions sont aussi vérifiées

Si l’action comporte une condition, celle-ci est évaluée avant l’exécution. L’enregistrement concerné peut avoir changé depuis la planification. Si la condition n’est plus satisfaite, l’action passe à l’état Omission (Skipped) avec un motif. Consultez Exécution conditionnelle pour construire ces conditions.

Depuis la version 1.14, les actions déclenchées par une réponse respectent leurs conditions. Si une action passe à Omission (Skipped) après la mise à niveau, consultez le motif enregistré au lieu de supposer que le rapprochement n’a pas fonctionné.

Suivi du traitement

Actions planifiées — consultez l’état, les erreurs éventuelles, l’identifiant du message sortant suivi et son objet. Selon le résultat, l’action peut être exécutée, ignorée, remise en attente ou marquée en échec.
Conversations — lorsque l’analyse IA utilise la conversation d’origine, la réponse et le nouvel échange y sont ajoutés pour conserver l’historique.
Journal des incidents — recherchez les erreurs consignées pendant la lecture ou le traitement des messages. Certains chemins enregistrent aussi l’échec sur l’action ou dans les journaux de débogage ; l’absence d’incident ne prouve pas la réussite. Le Flow ne fournit pas à lui seul un mécanisme de nouvelle tentative.

Sécurité et gouvernance

Vérifiez l’utilisateur d’exécution réel. Il dépend de l’infrastructure de réception et du contexte Flow. Les lectures de messages et d’actions utilisent le mode utilisateur ; leurs autorisations et leur partage doivent permettre les correspondances attendues.
Une correspondance n’authentifie pas l’expéditeur. Le code rapproche des messages entrants d’actions en attente par parent ou objet. Il ne garantit pas qu’un message indésirable, un rejet ou une réponse provenant d’un tiers ne corresponde jamais. Contrôlez les entrées et les opérations sensibles dans votre configuration.
Les objets identiques peuvent entrer en collision. La comparaison ignore la casse après normalisation des préfixes. Des actions sans rapport peuvent partager le même objet ; utilisez un identifiant distinctif et testez les cas de collision.
Une action déclenchée par réponse attend une correspondance. Elle ne s’exécute pas simplement parce qu’un délai expire. Ajoutez une action temporisée si vous souhaitez aussi relancer en l’absence de réponse.

Bonnes pratiques

Associez send_email et schedule_action au même groupe. Créez d’abord les actions en attente, puis envoyez le message avec la même clé group_key pour permettre leur liaison.

Choisissez des objets distinctifs. La comparaison par objet s’applique même après un résultat par parent. Un identifiant propre à l’échange réduit les correspondances ambiguës.

Réservez l’analyse IA aux réponses qui la nécessitent. Elle consomme des crédits et mobilise le contexte de l’agent. Pour une opération fixe et autorisée, un contenu d’action prédéfini est plus prévisible.

Associez réponse et délai de secours. Prévoyez une action sur réponse et une action temporisée dans le même groupe. Vérifiez l’annulation des actions sœurs et les conditions pour éviter une relance devenue inutile.

Limitez le périmètre du Flow. Appliquez au minimum Incoming = TRUE, puis les critères nécessaires aux boîtes et cas d’usage visés. Les lectures et traitements consomment des ressources Salesforce.

Questions fréquentes

Il faut une infrastructure de réception qui crée des EmailMessage entrants. Email-to-Case est une possibilité ; un gestionnaire de service de messagerie personnalisé peut aussi convenir. Un relais de messagerie seul ne garantit pas la création de ces enregistrements : vérifiez un message reçu réel.

Les requêtes dynamiques évitent la dépendance de compilation, mais le suivi ne peut pas se déclencher sans messages disponibles. Les agents peuvent toujours envoyer des e-mails et planifier des actions temporisées, selon la configuration Salesforce.

Le rapprochement utilise un traitement asynchrone, des requêtes dynamiques, la normalisation des objets et un éventuel appel à l’agent. L’action invocable regroupe ces opérations pour simplifier le Flow client.

Une action qui a quitté l’état d’attente après traitement réussi n’est plus sélectionnée. Pour poursuivre plusieurs échanges, créez une nouvelle action en attente avant chaque nouvel envoi suivi. Une action remise en attente après erreur peut être retentée.

La comparaison d’objet reste possible : les préfixes de réponse ou transfert sont retirés, puis la comparaison ignore la casse. Toutes les actions en attente correspondantes peuvent être retenues. Cette recherche s’applique aussi lorsqu’un parent a produit un résultat.

Oui. Le champ Traitement par IA active ce traitement. Le corps de la réponse devient un message pour l’agent et peut poursuivre la conversation associée à l’action.

Le Flow peut appeler le gestionnaire, mais après les lectures et vérifications initiales, l’absence d’action en attente provoque une sortie sans traitement Queueable. Cela consomme tout de même des requêtes et des ressources Salesforce.

Étapes suivantes

Consultez Actions planifiées pour le cycle de vie et les suivis temporisés, ou Canal e-mail — Envoi pour l’association avec group_key.

← Précédent : Canal e-mail — Envoi

Suivant : Saisie vocale →