Services e-mail : configuration et activation
Ce guide décrit l’activation des services e-mail REDA : associer les messages clients aux enregistrements et créer des demandes de renseignements ou de service depuis des adresses dédiées. Attribuez les accès, configurez le service de réception et son adresse Salesforce, préparez le routage de messagerie, puis les métadonnées et présentations. L’activation repose sur cet ensemble de prérequis, sans bouton général unique de synchronisation. Suivez les étapes et vérifiez chaque parcours par un test ; une installation seule ne confirme pas que les trois fonctions sont opérationnelles.
Avant de commencer
- Confirmez le package REDA OEM installé, sa version et la présence des objets, de l’ensemble, de la page, des métadonnées et du gestionnaire nécessaires.
- Disposez des droits de Configuration appropriés pour gérer le service e-mail, son adresse, les métadonnées personnalisées et les présentations.
- Choisissez un utilisateur de contexte Salesforce licencié et actif, adapté au traitement automatisé. Vérifiez ses accès et attribuez l’ensemble spécialisé à l’étape 2 ; privilégiez un compte dont la disponibilité ne dépend pas d’un départ individuel.
- Préparez avec l’administrateur de messagerie Google Workspace ou Microsoft 365 les règles de copie ou de redirection de l’étape 4.
Étapes d’activation
REDA_Email_Integration . Attribuez REDA - Email Integration à l’utilisateur de contexte et aux personnes désignées pour le traitement manuel, puis vérifiez leurs droits complémentaires. Consultez À qui attribuer l’ensemble d’autorisations ci-dessous. …@…apex.salesforce.com pour votre organisation et vérifiez les expéditeurs autorisés au niveau du service et de l’adresse. À qui attribuer l’ensemble d’autorisations
L’ensemble REDA - Email Integration (nom d’API REDA_Email_Integration) accorde la création, la lecture, la modification et la suppression sur E-mail sans correspondance, la visibilité de l’onglet, les droits des composants associés et la modification des deux champs Contact Omni Inbox. Il ne représente pas à lui seul tous les droits nécessaires sur les destinations, les fichiers ou la Configuration. Vérifiez les deux rôles suivants :
| Rôle | Accès à vérifier |
|---|---|
| Utilisateur de contexte du service | Le service traite les messages sous ce contexte. Attribuez les droits spécialisés et vérifiez la licence, l’activation, les accès nécessaires et le comportement avec les règles de l’organisation. Ne prenez pas le résultat d’un test administrateur pour la preuve de tous les accès. |
| Administrateurs ou agents chargés du traitement manuel | Ils ont besoin de l’onglet, des enregistrements, du panneau Faire correspondre à un enregistrement et des accès aux destinations et fichiers qu’ils doivent traiter. |
Paramètres du service de réception
À l’étape 3, ouvrez le service REDA InboundEmail Handler s’il existe. Sinon, créez un service lié à la classe du package REDA_EmailInboundHandler. Vérifiez les paramètres ci-dessous et l’adresse cliente ; la configuration d’une organisation de packaging ne prouve pas celle de votre organisation. Les noms anglais des contrôles Salesforce sont conservés pour faciliter leur repérage si votre écran n’est pas traduit.
| Paramètre | Valeur ou contrôle | Raison |
|---|---|---|
| Classe de traitement (Apex Class) | REDA_EmailInboundHandler, classe fournie par le package | Elle reçoit les messages et applique les règles de classement et de création. Vérifiez sa sélection sur le service ; vous n’avez pas à développer une nouvelle classe pour ce parcours. |
| Active (Actif) | Coché sur le service et sur l’adresse utilisée | Le service et l’adresse doivent tous deux être actifs pour recevoir les messages prévus. |
| Accept Attachments (Accepter les pièces jointes) | All (Toutes) | Permet au gestionnaire de recevoir les types de pièces jointes pris en charge. Les limites Salesforce et les erreurs d’enregistrement restent applicables ; ce réglage ne garantit pas la conservation de tout fichier. |
| Over Email Rate Limit Action (Dépassement de limite) | Requeue Message (Remettre en file d’attente), selon le besoin de continuité validé | Permet de reporter les messages admissibles après dépassement de la limite quotidienne. La file a elle-même une limite et les messages supplémentaires peuvent être retournés ; ce réglage ne constitue pas une garantie de réception sans limite. |
| Advanced Email Security Settings / Authenticate Senders | Configurer et tester l’authentification avec l’administrateur de messagerie | L’authentification peut rejeter des copies dont les mécanismes d’authentification ne sont pas préservés. Ne la désactivez pas automatiquement : vérifiez le routage, les expéditeurs acceptés et les actions d’échec appropriées à votre organisation. |
| Actions pour adresse ou service désactivé, échec d’authentification ou expéditeur non autorisé | Choix explicite ; Bounce Message (Retourner le message) fournit un retour d’échec | Un réglage Discard Message (Ignorer le message) peut supprimer le message sans traitement. Vérifiez chaque action et le destinataire réel des erreurs dans votre routage de copies. Ces réglages Salesforce ne remplacent pas les journaux des erreurs que le gestionnaire REDA intercepte. |
Acheminer les messages vers Salesforce
REDA ne se connecte pas directement à votre fournisseur de messagerie pour lire une boîte. Votre routage lui transmet les copies. Vérifiez comment ce routage conserve l’expéditeur, les destinataires et le contexte de fil :
| Méthode | Usage | Précisions |
|---|---|---|
| Copie côté serveur (Cci / also deliver to) | Méthode recommandée pour conserver aussi l’original | Achemine une copie à Salesforce tout en livrant le message à la boîte prévue. Vérifiez par test que les données de l’expéditeur et du fil sont préservées ; le comportement dépend de la règle configurée. |
| Redirection côté serveur | Possible selon le parcours validé | Peut préserver l’expéditeur en dirigeant le message vers Salesforce. Vérifiez aussi où l’original est livré et les en-têtes conservés. |
| Forward ordinaire depuis la messagerie personnelle | À éviter comme substitut au routage validé | Le transfert peut présenter l’agent comme expéditeur. Le service ne reconstitue pas automatiquement le prospect depuis le texte transféré ; la copie peut être associée à une mauvaise personne, classée comme sortante ou interne, ou mise en attente selon sa configuration. |
L’administrateur de messagerie configure la règle Google Workspace ou Microsoft 365 vers l’adresse Salesforce vérifiée à l’étape 3. REDA ne traite que les copies effectivement reçues ; testez les sens entrant et sortant si les deux sont requis.
Configurer les domaines internes
REDA utilise vos domaines internes pour distinguer les copies sortantes des messages clients reçus et écarter les échanges exclusivement internes reconnus. La liste se trouve dans l’enregistrement de configuration portant la clé Email_Internal_Domains.
Champs des présentations
Affichez les champs nécessaires à la configuration et au traitement sur les pages appropriées :
| Objet / présentation | Champ | Rôle |
|---|---|---|
| Région | Contact Omni Inbox | Contact par défaut pour l’activité d’une demande de renseignements sans contact correspondant, lorsque le champ de remplacement de la demande est vide. |
| Demande de renseignements | Contact Omni Inbox (remplacement) | Contact prioritaire sur la valeur régionale pour l’activité de cette demande, si aucun contact client n’est reconnu. |
| Demande de renseignements | Source de la demande et E-mail | Affiche l’origine et l’adresse reçue. La valeur de source E-mail doit être prévue dans les valeurs par défaut de l’adresse ; afficher le champ ne la renseigne pas automatiquement. |
| Demande de service | Objet de la demande, Description de la demande, Contact | Objet du message limité à 255 caractères, corps texte limité à 2 000 caractères et contact reconnu, sous réserve des valeurs par défaut et des règles applicables. |
Configurer les adresses de création de demandes
La synchronisation de base utilise le service et les copies ; les domaines internes sont nécessaires aux comportements décrits plus haut. Les parcours de création de demandes nécessitent en plus une configuration active par adresse, avec le type d’objet voulu. Les deux exemples fournis illustrent ce paramétrage :
| Enregistrement d’exemple | Type de réception | Usage illustré |
|---|---|---|
| REDA Example - Leasing | Demande | Un message admissible à l’adresse de location crée ou réutilise une demande de renseignements, sauf contexte de fil prioritaire. |
| REDA Example - Support | Demande de service | Un nouveau message admissible à l’adresse de support peut créer une demande de service ; les réponses reconnues suivent leur fil. |
Adaptez ces exemples ou créez les lignes nécessaires pour vos adresses réelles, avec une seule configuration active par adresse et le type approprié. Évitez les doublons et les messages adressés simultanément à plusieurs adresses de création : le sélecteur ne fournit pas une priorité métier explicite entre plusieurs correspondances. Chaque ligne peut définir un type d’enregistrement et des valeurs par défaut. Consultez E-mail vers une demande de renseignements et E-mail vers une demande de service.
reda.example. Ces adresses illustratives ne configurent pas votre messagerie. Remplacez-les par les adresses réelles destinataires de vos copies et vérifiez leur présence dans les en-têtes reçus.Le type de métadonnées personnalisées Email Service Config conserve ces lignes dans la Configuration Salesforce ; son nom n’est pas traduit dans le package. Il comporte notamment les champs suivants :
| Champ | Valeur à renseigner |
|---|---|
| Adresse du service d'e-mails | Adresse publique de réception reconnue parmi les destinataires du message, par exemple la boîte de location. Ne la confondez pas automatiquement avec l’adresse technique Salesforce générée : vérifiez les adresses réellement conservées dans les en-têtes de la copie. |
| Type de réception | Demande ou Demande de service, selon l’objet à créer. Ces valeurs françaises correspondent aux types Inquiry et Service Request. |
| Nom d'API du type d'enregistrement | Facultatif : nom développeur du type applicable à l’objet. Vérifiez qu’il est disponible pour le contexte ; une valeur non reconnue n’impose pas ce type. |
| Valeurs de champ par défaut (JSON) | Facultatif : valeurs initiales utilisant les noms d’API exacts des champs. Elles sont appliquées après les données préparées et peuvent les remplacer. Un JSON invalide ou un champ incompatible peut être ignoré ; testez les valeurs réellement créées. |
| Actif | Décochez pour désactiver cette règle de création sans la supprimer. Cela ne coupe pas le service : le message peut encore suivre le classement ou la mise en attente habituels. |
Vérifier le fonctionnement
Après configuration, testez chaque parcours de bout en bout :
Pour aller plus loin
- Services e-mail REDA : présentation : comprendre les fonctions.
- Synchronisation automatique des e-mails : correspondances et contexte du fil.
- E-mail vers une demande de renseignements : création et réutilisation des demandes.
- E-mail vers une demande de service : création des demandes de support.
- Traiter les e-mails sans correspondance : association manuelle des messages conservés.
- Services e-mail : dépannage : réception absente ou correspondance manquante.
Questions fréquentes
Salesforce génère une adresse lorsque vous ajoutez une adresse au service dans l’organisation. Vérifiez ou créez cette adresse, son utilisateur de contexte et son activation, puis copiez la valeur générée de type …apex.salesforce.com. Ne réutilisez pas une adresse d’une autre organisation.
L’activation repose sur le service, son adresse, les copies et les accès. Les domaines internes et les configurations de réception déterminent ensuite les comportements attendus. Il n’existe pas de bouton unique qui valide tous ces prérequis.
Utilisez une copie ou une redirection côté serveur validée avec l’administrateur de messagerie. Un transfert ordinaire peut modifier l’expéditeur et entraîner une autre correspondance, une classification sortante ou interne, ou une mise en attente ; il ne préserve pas automatiquement l’identité du client.
La configuration doit refléter vos domaines réels pour distinguer les copies sortantes et filtrer les messages exclusivement internes. Une valeur d’exemple est insuffisante. Si la liste est vide, cette distinction est désactivée et toutes les copies sont traitées comme entrantes.
Évaluez Requeue Message pour le dépassement de limite, en tenant compte de sa file bornée. Choisissez explicitement les autres actions : Bounce Message fournit un retour d’échec, tandis que Discard Message peut supprimer le message sans traitement. Testez les retours avec votre routage et surveillez aussi les journaux REDA, car les erreurs interceptées par le gestionnaire ne déclenchent pas forcément un retour Salesforce.
Cet article vous a-t-il été utile ?