Résoudre les problèmes du canal e-mail

Trois parcours de courriel Les problèmes de messagerie de REDA AI concernent la réception de courriels et de documents, l’envoi par l’agent ou le suivi des réponses à ses courriels. Identifiez d’abord le parcours concerné : les causes et les contrôles diffèrent.

Où chercher en premier

Réception : le gestionnaire REDA AI n’envoie pas automatiquement de réponse. Recherchez les incidents disponibles et vérifiez le service de messagerie ; tous les messages ignorés ne produisent pas un incident.
Envoi : les échecs peuvent apparaître dans le résultat structuré de l’outil sur la conversation et dans un journal d’incidents.
Suivi des réponses : le symptôme est souvent une action programmée qui ne s’exécute pas. Examinez ensemble cette action, le courriel entrant et les incidents éventuels.

Pour approfondir un incident, lancez Déboguer avec l’IA. Pour vérifier la configuration, ouvrez l’aperçu d’exécution de l’agent.

Courriels entrants : réception

Le gestionnaire REDA AI accepte les courriels sans envoyer lui-même de rejet ni d’accusé de réception. Cela ne garantit pas la livraison par toute l’infrastructure de messagerie. Un courriel correctement routé peut atteindre l’agent avec ou sans pièce jointe. Distinguez l’absence totale d’exécution de l’agent de l’absence de fichiers dans une exécution existante.

Symptôme : les courriels arrivent à l’adresse, mais l’agent ne s’exécute pas

Vérifiez d’abord le service et le routage actif de l’adresse, puis les éventuelles erreurs de traitement, de licence ou d’exécution : un routage existant ne garantit pas à lui seul la réussite de l’agent.

1. Le service de messagerie Salesforce n’est pas configuré

Le service de messagerie Salesforce doit utiliser le gestionnaire REDA AI pour lui transmettre les courriels entrants.

À vérifier :

Dans Configuration › Services de messagerie, vérifiez que le service est actif et utilise la classe de gestionnaire REDA AI.
Vérifiez qu’au moins une adresse de service a été générée et activée.
Si vous souhaitez traiter des pièces jointes, choisissez l’option Accept Attachments définie sur All dans une interface Salesforce en anglais, afin d’accepter les pièces jointes binaires et textuelles.

2. Aucun routage ne correspond à l’adresse de réception

Un routage actif associe l’adresse à un agent. Sans correspondance, un courriel sans fichier enregistré est ignoré ; si des pièces jointes ont été enregistrées, le traitement tente de signaler l’absence de routage dans un incident. Dans les deux cas, aucun agent n’est sélectionné.

À vérifier dans Administrateur IA REDA › Opérations › Routage du courrier électronique :

Une entrée existe pour cette adresse et renseigne son libellé, son adresse de courriel et son agent ; elle est active.
Une entrée grisée est désactivée. Utilisez l’icône de validation pour la réactiver si ce routage est souhaité.
La correspondance utilise l’adresse complète ou la partie située avant @, après normalisation de la casse et des espaces. Les caractères génériques et le routage par domaine ne sont pas pris en charge. Évitez des entrées qui se chevauchent : la priorité entre une adresse complète et sa partie locale n’est pas garantie.
Le sélecteur de routage propose les agents actifs du canal API. Les agents des canaux Interne, Communauté et Widget externe ne sont pas proposés dans ce parcours côté serveur.

Symptôme : l’agent s’exécute, mais ne voit pas les pièces jointes

Le courriel atteint l’agent, mais les fichiers attendus ne sont pas joints à la conversation. Vérifiez le traitement des pièces jointes : le corps du courriel peut être transmis sans elles.

1. Le traitement des pièces jointes est désactivé

Le paramètre Traitement des fichiers de messagerie électronique contrôle les pièces jointes et est désactivé par défaut. Dans ce cas, un courriel routé peut toujours créer une conversation, mais ses pièces jointes sont ignorées, sans fichier enregistré ni incident pour ce seul motif.

À vérifier : activez Traitement des fichiers de messagerie électronique dans l’administration REDA AI si les fichiers entrants doivent être enregistrés et transmis à l’agent.

2. Les pièces jointes ont été filtrées

Lorsque le traitement est activé, les filtres peuvent écarter les fichiers avant leur transmission à l’agent :

Les fichiers binaires de moins de 10 Ko environ et les pièces jointes textuelles très courtes sont ignorés comme logos ou signatures. Les seuils minimaux du gestionnaire sont définis dans le package ; ce ne sont pas tous des paramètres administrables.
Les extensions absentes du paramètre Extensions de fichiers autorisées sont refusées. Les fichiers dépassant la taille maximale sont également écartés.

Si toutes les pièces jointes sont filtrées, un courriel routé peut toujours être traité à partir de son corps, sans fichier. Ce filtrage peut aussi écarter un véritable document très petit.

À vérifier :

Le paramètre Extensions de fichiers autorisées contient les formats envoyés.
La taille réelle des fichiers, y compris les minima de filtrage et la taille maximale configurée.

Symptôme : une pièce jointe a été enregistrée, puis l’agent a échoué

Si le traitement du courriel reçoit une erreur du service IA, il tente de créer un incident avec l’erreur, l’expéditeur et l’objet du courriel. Les chaînes techniques peuvent rester en anglais : « Email file processing error: … » et « Email file processing failed ». Une exception sur un autre parcours peut produire un incident différent, sans tous ces éléments.

À vérifier :

La conversation éventuellement créée et le résultat disponible. Un échec précoce ne garantit pas l’existence d’un message assistant contenant l’erreur.
L’incident correspondant : l’adresse d’expédition et l’objet, lorsqu’ils sont présents, permettent de retrouver le courriel concerné.
Lancez Déboguer avec l’IA sur l’incident si le message ne suffit pas à expliquer l’échec.

Symptôme : aucun accusé de réception n’a été envoyé

Le gestionnaire entrant REDA AI n’envoie pas automatiquement de réponse, de rejet ou d’accusé de réception. Pour un accusé de réception métier, configurez explicitement l’agent et son outil d’envoi sortant. Vérifiez séparément les réponses automatiques de Salesforce ou de votre infrastructure de messagerie.

Courriels sortants : envoi par l’agent

Les erreurs d’envoi sont renvoyées à l’agent dans le résultat structuré de l’outil, consultable dans la transcription de la conversation.

Symptôme : « Échec de l'envoi du courriel : … »

Ce message signale un échec de l’envoi. Le texte après les deux-points fournit le détail renvoyé par Salesforce.

À vérifier :

L’erreur précise : délivrabilité restreinte, limite quotidienne d’envoi Apex, problème d’enregistrement du courriel ou adresse d’organisation non utilisable peuvent empêcher l’envoi.
Dans les paramètres Salesforce de délivrabilité, vérifiez que le niveau d’accès autorise les courriels nécessaires au test.
Dans une sandbox également, les courriels sortants ordinaires de l’agent nécessitent All Email dans une interface anglaise. « System Email Only » autorise les messages système et ne suffit pas pour tester ce parcours d’envoi.

Symptôme : le courriel a été envoyé, mais n’est pas lié à un contact ou à un prospect

Le mécanisme standard recherche d’abord un contact dont l’adresse correspond, puis un prospect non converti. Il peut utiliser une première correspondance : les doublons ne garantissent pas l’absence de lien et peuvent entraîner une association indésirable. Sans correspondance accessible, le courriel peut être envoyé sans ce lien.

À vérifier :

L’adresse du destinataire dans les contacts et prospects non convertis, ainsi que les doublons éventuels.
Les droits de l’utilisateur d’exécution sur ces objets, leurs champs d’adresse et leurs enregistrements. La recherche s’effectue en mode utilisateur ; un échec de lecture peut laisser le destinataire sans association.
L’adresse réellement fournie par l’agent : la recherche compare la valeur d’adresse.

Symptôme : l’expéditeur est l’utilisateur d’exécution, pas l’adresse de marque

Le parcours standard sélectionne une adresse d’organisation accessible selon sa configuration, ou utilise l’utilisateur d’exécution lorsqu’aucune adresse n’est retenue. Vérifiez que l’adresse d’organisation est vérifiée et autorisée pour tous les profils ; l’existence de plusieurs adresses ne garantit pas que la marque souhaitée sera choisie.

À vérifier :

Dans les adresses d’organisation de Salesforce, l’adresse de marque est vérifiée.
Son option d’accès à tous les profils est activée pour le mécanisme standard décrit ici. Vérifiez ensuite l’expéditeur réel sur un envoi de test.

Symptôme : les signatures diffèrent selon les utilisateurs

Le parcours standard utilise la signature Salesforce de l’utilisateur d’exécution lorsqu’elle existe ; sinon, il construit une signature à partir de ses informations, notamment son nom, son rôle et son adresse.

À vérifier :

La signature de chaque utilisateur dans ses paramètres personnels de messagerie.
Si une signature centralisée est nécessaire, évaluez un outil d’envoi personnalisé utilisant un modèle de courriel, puis testez le résultat dans votre configuration et votre version.

Symptôme : un grand volume d’envois finit par échouer

L’envoi utilise Salesforce Messaging.SingleEmailMessage et reste soumis aux limites Salesforce applicables, notamment les quotas quotidiens d’envoi Apex. Une limite atteinte peut empêcher de nouveaux envois jusqu’à sa réinitialisation.

À vérifier : les limites et la consommation d’envoi dans Salesforce. Répartir les actions réduit les pics, mais ne relève pas un quota quotidien ; adaptez le volume total et vérifiez les résultats avant une relance.

Suivi des réponses

Le suivi recherche des actions programmées en attente à partir des courriels entrants enregistrés dans Salesforce. Une absence d’exécution peut être silencieuse ; vérifiez aussi les conditions et les erreurs de l’action.

Symptôme : le destinataire a répondu, mais l’action programmée ne s’est pas exécutée

Vérifiez d’abord le paramètre principal, puis les six points suivants :

0. Le suivi des réponses est désactivé par défaut. Le paramètre Suivi des réponses par e-mail est livré désactivé. Le gestionnaire s’arrête lorsqu’il est désactivé, sans incident pour ce seul motif. Activez-le dans Administration de l’IA REDA › Configuration › Système et notifications avant d’examiner les points suivants.

Vérifiez aussi la configuration Salesforce, notamment Enhanced Email selon le parcours utilisé : le mécanisme exige des enregistrements EmailMessage entrants effectivement créés et accessibles.

1. La réponse n’est jamais arrivée dans Salesforce

Le suivi dépend d’enregistrements EmailMessage entrants. Email-to-Case ou une autre intégration doit enregistrer les réponses ; une réponse restée uniquement dans une boîte de messagerie n’est pas visible par ce mécanisme.

À vérifier : la réponse a créé un enregistrement EmailMessage. Sinon, corrigez le routage de l’infrastructure de messagerie vers Salesforce.

2. Le Flow déclenché sur EmailMessage n’est pas configuré

La plateforme ne recherche pas périodiquement tous les EmailMessage. Un Flow configuré dans l’organisation doit appeler l’action Apex invocable « Process Inbound Emails » après la création des courriels entrants.

À vérifier :

Dans Configuration › Flows, le Flow existe, est actif et s’exécute après la création d’un enregistrement EmailMessage.
Sa condition d’entrée inclut Incoming = TRUE, afin d’exclure les courriels sortants.
Il appelle l’action Apex « Process Inbound Emails » avec l’identifiant de l’enregistrement déclencheur.

3. Le courriel sortant et l’action ne sont pas associés

Dans le parcours d’association automatique, la valeur group_key permet de relier l’envoi aux actions programmées concernées. Vérifiez aussi les références de courriel suivies sur l’action : le rapprochement entrant utilise ces références et l’objet du courriel.

À vérifier : le prompt et la configuration fournissent une valeur group_key cohérente aux appels send_email et schedule_action. Utilisez une clé propre au processus ; une clé partagée trop largement peut aussi regrouper et annuler des actions sans rapport.

4. L’action n’était plus en attente à l’arrivée de la réponse

Le rapprochement ne retient que les actions de réponse par courriel encore en attente. Une action exécutée, omise, échouée ou annulée ne sera pas activée par ce mécanisme.

À vérifier : le statut, le résultat et l’historique de l’action. Un statut différent d’en attente ne prouve pas une exécution réussie : l’action peut avoir été annulée ou omise.

5. Plusieurs actions correspondent au même objet de courriel

Le mécanisme utilise la référence parent Salesforce et compare aussi les objets normalisés, en retirant des préfixes comme Re: et Fwd:. Les correspondances par objet peuvent s’ajouter même lorsqu’une référence parent correspond déjà. Plusieurs actions peuvent donc être sélectionnées ; le mécanisme ne garantit pas une correspondance unique avec le destinataire attendu.

À vérifier : utilisez des objets distinctifs pour les processus simultanés. Des objets génériques comme « Mise à jour » ou « Relance » risquent d’associer une réponse à une action sans rapport.

6. Le contexte d’exécution ne peut pas lire les actions programmées

La requête de rapprochement s’exécute en mode utilisateur. Vérifiez l’identité réellement utilisée par le Flow et le traitement en arrière-plan, ainsi que ses droits : ne supposez pas qu’il s’agit toujours du même utilisateur système.

À vérifier : les autorisations sur l’objet des actions programmées, ses champs et le partage des enregistrements pour cet utilisateur.

Symptôme : une autre réponse a activé l’action

Vérifiez les objets identiques et les références parent partagées. Des objets distincts, des groupes propres à chaque processus et une configuration de liaison Salesforce cohérente réduisent les collisions ; la présence d’une référence parent n’exclut pas les autres correspondances par objet.

Procédure d’investigation d’un courriel

Identifier le parcours de courriel.
Identifiez la réception, l’envoi par l’agent ou le suivi des réponses. Chaque parcours possède ses propres points de contrôle.
Réception : vérifiez le service, le routage, les fichiers et les incidents disponibles. L’absence d’incident ne prouve pas que le courriel a atteint l’agent.
Envoi : ouvrez la transcription et le résultat de l’appel d’outil concerné pour lire l’erreur Salesforce disponible.
Suivi des réponses : ouvrez l’action et son résultat. Le statut En attente peut correspondre à une absence de rapprochement ou à un échec encore susceptible d’être repris. Exécuté indique que l’action a été traitée ; vérifiez le résultat métier. Examinez aussi les conditions, les tentatives et les annulations du groupe.
Lancer Déboguer avec l’IA.
Utilisez les questions de suivi pour approfondir les hypothèses, puis vérifiez les faits. Voir Déboguer avec l’IA.

Questions fréquentes

Vérifiez d’abord le service Salesforce, son adresse active et un routage actif vers l’agent. Un courriel sans fichier enregistré et sans routage est ignoré sans incident. Si l’agent s’exécute sans fichier, vérifiez le traitement des pièces jointes, leurs extensions et leurs tailles. Si tout est correct, examinez les erreurs d’exécution et les traitements en arrière-plan.

Ils figurent dans le message de l’incident lorsque le traitement du courriel reçoit une erreur du service IA et l’enregistre avec ce contexte. D’autres erreurs peuvent produire un incident moins détaillé ; rapprochez aussi les heures, le courriel et la conversation.

Consultez le résultat structuré de l’outil dans la conversation : il peut contenir le détail Salesforce après les deux-points, même si la réponse de l’agent l’a résumé. Recherchez également un incident si le résultat reste incomplet.

Comparez les références parent, les objets normalisés, le statut et les conditions des actions, ainsi que les droits d’exécution. Plusieurs correspondances peuvent être retenues par référence parent ou par objet ; des objets distinctifs réduisent les collisions sans garantir une association unique.

Oui, si une autre configuration crée les réponses entrantes comme enregistrements EmailMessage accessibles, puis appelle l’action de traitement depuis le Flow prévu. Sans ces enregistrements et cet appel, le mécanisme ne peut pas suivre les réponses.

Configurez et vérifiez une adresse d’organisation autorisée pour tous les profils dans Salesforce. Testez ensuite le parcours standard et l’expéditeur réellement retenu, surtout si plusieurs adresses existent. Sans adresse sélectionnée, l’envoi peut utiliser l’utilisateur d’exécution.

Vérifiez l’activation du traitement, l’extension autorisée et les limites de taille. Les seuils minimaux qui écartent les fichiers assimilés à des signatures sont définis dans le gestionnaire ; la liste des extensions et la taille maximale sont configurables. Un fichier légitime très petit peut donc être filtré.

Non. Le routage compare l’adresse complète ou la partie avant @. Les caractères génériques et les correspondances par domaine ne sont pas pris en charge. Créez les entrées nécessaires et évitez les chevauchements entre adresses complètes et parties locales.

Étapes suivantes

Consultez Journaux d’incidents d’IA pour comprendre les enregistrements techniques, puis le guide du parcours concerné : Canal e-mail entrant, Canal e-mail sortant ou Traitement des réponses par courriel.

← Précédent : Résoudre les problèmes de traitement des documents

Suivant : Journaux d’archivage de l’IA →