REDA One Centre d’aide
FR
Langue
English EN Español ES Português PT Italiano bientôt disponible Français FR Deutsch bientôt disponible العربية bientôt disponible
reda.one ↗
Accueil / REDA One / Intégrations / REDA Email Services / Services e-mail : dépannage

Services e-mail : dépannage

Les services e-mail REDA traitent les copies reçues pour les associer aux contacts, créer des demandes ou placer certains messages en attente de correspondance. Si des messages ou des pièces jointes manquent, ce guide aide à distinguer les problèmes d’acheminement, de configuration, de correspondance et de traitement. Chaque cause est une hypothèse à vérifier à partir du message et des journaux concernés ; les paramètres sont décrits dans Services e-mail : configuration.

La suite décrite est fournie dans l’édition Platform (OEM). Le package REDA Sales Cloud ne fournit pas ce parcours à l’identique. Confirmez l’édition et la version avant d’appliquer ces contrôles.
Utiliser ce guide. Chaque section suit le format problème → cause à vérifier → action. Commencez par le symptôme observé et confirmez la cause avant de modifier la configuration. Si plusieurs hypothèses s’appliquent, vérifiez d’abord les prérequis de réception.
Vous utilisez REDA Sales Cloud ? Platform utilise Demande de renseignements au lieu de Piste et Demande de service pour certains parcours comparables à Requête. Cette comparaison ne signifie pas que la suite e-mail OEM existe à l’identique dans Sales Cloud. Consultez Éditions REDA.

Aucun message ni enregistrement n’apparaît

Vous attendez une activité ou une nouvelle demande. Vérifiez successivement la réception réelle, les paramètres et le traitement :

ProblèmeCause à vérifierAction
Aucun e-mail n’est associé et aucune demande n’est créée. Le service ou son adresse peut être inactif. Vérifiez Active (Actif) sur le service et sur l’adresse Salesforce utilisée, ainsi que son utilisateur de contexte. Consultez Configuration.
Les messages de la boîte n’atteignent pas REDA. Les copies peuvent ne pas être acheminées vers la bonne adresse Salesforce. Vérifiez l’adresse générée pour cette organisation et la règle de copie ou de redirection côté serveur. Contrôlez la livraison et les en-têtes conservés ; REDA ne traite que les copies réellement reçues. Consultez Configuration.
Les messages de certains expéditeurs manquent. Une restriction d’expéditeur ou un contrôle d’authentification peut les refuser. Vérifiez Accept Email From (expéditeurs acceptés) au niveau du service et de l’adresse, l’authentification et les actions d’échec. Corrigez une restriction trop étroite selon le routage prévu ; ne videz pas systématiquement la liste. Le résultat dépend de l’action configurée, et n’est pas toujours une suppression silencieuse.
Un message destiné à créer une demande n’en crée aucune. L’adresse reçue peut ne correspondre à aucune configuration active, ou un contexte de fil peut orienter le message ailleurs. Vérifiez une seule ligne active par adresse, avec le type Demande ou Demande de service, et les destinataires réellement présents dans les en-têtes. Sans configuration applicable, le message peut encore être classé ou mis en attente par la synchronisation. Consultez E-mail vers une demande de renseignements et E-mail vers une demande de service.
Les utilisateurs ne voient pas les messages pourtant traités. Des droits ou une configuration de page peuvent manquer. Vérifiez REDA - Email Integration pour les personnes chargées du traitement manuel, puis les droits effectifs, le partage, les destinations, les fichiers et les présentations. L’absence de cet ensemble ne prouve pas à elle seule l’absence de tout droit équivalent.

De nombreux messages sont sans correspondance

La liste E-mails sans correspondance confirme que certains messages ont atteint la mise en attente. Examinez leur expéditeur, leur type, leur contexte de fil et les journaux avant de conclure à une cause commune.

ProblèmeCause à vérifierAction
L’expéditeur affiché est votre propre boîte plutôt que le client. Un transfert ordinaire peut avoir modifié l’identité de l’expéditeur reçu. Vérifiez les en-têtes et remplacez le Forward personnel par une copie côté serveur ou une redirection validée préservant les données attendues. Selon les domaines internes, un transfert peut aussi être classé sortant ou ignoré ; il ne conduit pas systématiquement à la liste sans correspondance.
Des messages clients sont classés dans le mauvais sens ou ignorés. La liste des domaines internes peut inclure un domaine client ou omettre vos domaines. Vérifiez la valeur Email_Internal_Domains et les domaines exacts, y compris les sous-domaines utilisés. Une liste vide laisse toutes les copies traitées comme entrantes ; une liste incorrecte peut changer l’interlocuteur recherché ou entraîner un filtrage interne. Consultez Configuration.
Les messages de nouveaux prospects restent sans correspondance. Aucun contact, contexte de fil, demande de repli ou parcours de création applicable n’a été trouvé. Ce résultat peut être attendu pour un message de synchronisation sans destination. S’il doit créer une demande, configurez l’adresse et le type Demande ou Demande de service, puis testez le parcours. Une adresse inconnue peut malgré tout être reconnue par le fil ; vérifiez le cas précis.
Diagnostic rapide. Comparez Adresse d'expéditeur avec le message d’origine. Si elle correspond à votre boîte, vérifiez le routage et les en-têtes avant de conclure à un transfert. Si un domaine client est considéré comme interne, corrigez la liste. Vérifiez aussi le type et les erreurs de création des éléments en attente.

Que deviennent les messages refusés par Salesforce ?

Salesforce applique des actions distinctes lorsque le service ou l’adresse est désactivé, qu’un expéditeur n’est pas autorisé, que l’authentification échoue ou qu’une limite est atteinte. Définissez ces actions explicitement. Elles ne couvrent pas nécessairement les erreurs que le gestionnaire REDA intercepte et journalise après réception.

SituationAction à évaluerEffet et limite
La limite quotidienne de traitement est atteinte. Requeue Message (Remettre en file d’attente). Reporte les messages admissibles pour un traitement ultérieur, avec une capacité de file limitée ; les messages supplémentaires peuvent être retournés. Discard Message peut supprimer le message sans traitement. Aucun de ces réglages n’offre une réception illimitée.
Service ou adresse désactivé, échec d’authentification ou expéditeur non autorisé. Bounce Message (Retourner le message), selon le routage validé. Fournit un retour d’échec. Vérifiez qui reçoit ce retour dans votre système de copies et comment l’équipe le surveille ; il ne garantit pas que le client ou l’administrateur l’a effectivement lu.
Vérifiez les valeurs réelles. La présence du service fourni ne valide pas les paramètres de votre organisation. Évaluez Requeue Message pour les limites et Bounce Message pour les échecs concernés, puis testez les retours et la surveillance conformément au guide Configuration.

Des pièces jointes manquent

Un message est enregistré, mais un fichier attendu n’est pas visible. Distinguez réception, enregistrement, liaison et accès au fichier :

ProblèmeCause à vérifierAction
Les messages apparaissent sans leurs pièces jointes. Le service peut ne pas accepter les pièces jointes, ou une limite ou erreur peut avoir empêché leur traitement. Vérifiez Accept Attachments = All (Toutes), puis la présence des pièces jointes dans la copie reçue, les limites et les journaux de stockage ou de liaison. Consultez Configuration. All ne garantit pas la conservation de chaque fichier.
Le fichier n’apparaît pas dans le corps de l’e-mail. Il peut être enregistré séparément, ou sa liaison ou son accès peut manquer. Les pièces jointes conservées deviennent des Fichiers. Vérifiez la liste Fichiers de l’enregistrement et les liens du message, puis vos droits. Si le fichier n’existe pas, examinez les journaux plutôt que de supposer un simple problème d’affichage.

Droits et accès

Si les messages sont traités mais non consultables, vérifiez les autorisations, le partage et la configuration de l’interface. Une erreur de traitement reste une autre explication à examiner.

ProblèmeCause à vérifierAction
L’utilisateur ne voit pas E-mails sans correspondance. Les droits ou la navigation de l’application peuvent manquer. Vérifiez REDA - Email Integration, la visibilité de l’onglet et la navigation. Cet ensemble fournit les droits spécialisés sur l’objet ; il ne l’ajoute pas nécessairement à toutes les applications.
L’utilisateur ouvre un élément, mais ne peut pas modifier les champs utiles. Les droits de champ, la présentation ou l’état du panneau peuvent empêcher l’action. Vérifiez les droits de REDA - Email Integration attribués à cet utilisateur, puis les droits effectifs, les champs de destination et le statut. Utilisez les actions Faire correspondre ou Ignorer du panneau pour le parcours normal, plutôt que de modifier directement les indicateurs.
Le traitement de réception échoue pour tous. Le contexte d’exécution ou une erreur commune de configuration, de données ou de traitement peut être en cause. Vérifiez l’utilisateur de contexte actif sur l’adresse, ses accès et l’ensemble REDA - Email Integration, puis les journaux, validations et limites. Les composants utilisent aussi des opérations système : l’absence de l’ensemble ne suffit pas à expliquer toute erreur. Consultez Configuration.

Pour aller plus loin

  1. Services e-mail : configuration : paramètres du service, de l’adresse et du routage.
  2. Traiter les e-mails sans correspondance : associer les messages conservés.
  3. Synchronisation automatique des e-mails : comprendre les correspondances attendues.
  4. Services e-mail REDA : présentation : les trois fonctions.

Questions fréquentes

Vérifiez Active sur le service et son adresse, l’utilisateur de contexte, l’arrivée réelle de la copie, les restrictions d’expéditeur et les filtres. Si vous attendez une création, vérifiez la configuration de réception active et le contexte de fil. Consultez ensuite les journaux pour distinguer absence de réception, réutilisation et erreur de création.

Vérifiez si un transfert a modifié l’expéditeur et si les domaines internes reflètent correctement votre organisation. Examinez aussi les adresses des contacts, le contexte de fil, les demandes existantes et les erreurs de création. Aucun de ces symptômes ne prouve à lui seul une cause unique.

Vérifiez Accept Attachments = All, la copie reçue, les limites, puis les erreurs d’enregistrement ou de liaison. Consultez la liste Fichiers et vos droits sur les fichiers associés. La réussite du message ne garantit pas celle de toutes ses pièces jointes.

Évaluez explicitement les actions selon votre besoin de continuité et de surveillance. Discard Message peut supprimer un message sans traitement ; Requeue Message est borné et Bounce Message fournit un retour d’échec pour les cas concernés. Testez les retours et consultez les journaux REDA : ces actions ne garantissent pas qu’aucun message ne sera perdu.

Cet article vous a-t-il été utile ?