Canal e-mail — Envoi

Fonctionnement de l’envoi

L’outil d’action intégré send_email envoie les e-mails. Lorsque l’agent l’utilise, la plateforme :

• Vérifie la présence du destinataire, de l’objet et du corps du message ;
• Recherche un contact puis un prospect correspondant à l’adresse du destinataire et associe le premier résultat accessible au message pour le suivi des activités ;
• Ajoute la signature Salesforce de l’utilisateur d’exécution, ou une signature de secours fondée sur son nom, son rôle et son adresse e-mail ;
• Utilise une adresse e-mail de l’organisation lorsqu’une adresse admissible est disponible ;
• Associe l’enregistrement concerné lorsqu’il est fourni et compatible avec le mécanisme Salesforce de suivi des activités ;
• Peut relier le message à des actions planifiées en attente de réponse pour reprendre le traitement lorsqu’une réponse correspondante arrive ;
• Demande l’enregistrement de l’e-mail dans les activités Salesforce.

L’agent peut envoyer un e-mail immédiatement avec send_email, ou le différer avec schedule_action, à une date future ou en fonction d’une réponse. Les deux modes utilisent le même mécanisme d’envoi.

Envoyer immédiatement avec send_email

Rendez l’outil intégré Référence des outils intégrés disponible pour les agents qui doivent envoyer des e-mails, selon leur canal et leur configuration. L’agent fournit :

L’outil send_email est une action. Dans le canal interne, sa configuration de confirmation peut présenter le brouillon complet à l’utilisateur avant l’envoi. Les canaux externes et automatisés ne présentent pas ces cartes et peuvent exécuter l’action automatiquement. Pour les appels Flow, l’entrée Auto-Execute Actions intervient dans le traitement des propositions restantes ; ce n’est pas un champ de la définition de l’agent. Consultez Confirmation des actions et limitez les outils aux opérations autorisées dans chaque canal.

Planifier avec schedule_action

Pour les suivis, rappels et messages déclenchés par une réponse, l’agent utilise schedule_action avec action_type défini sur Email. Le contenu est stocké dans une action planifiée, puis un traitement planifié effectue l’envoi lorsque ses conditions sont remplies.

Vous pouvez exprimer trois types de déclenchement :

• Date et heure fixes — envoi à un horodatage ISO 8601.
• Délai relatif — demande d’envoi dans un nombre de minutes, d’heures ou de jours, que l’agent doit convertir en date d’exécution.
• Réponse reçue — envoi après une réponse au message suivi dans le même groupe group_key, selon les règles de correspondance configurées.

Consultez Actions planifiées pour le modèle d’exécution et son suivi.

Ce que reçoit le destinataire

La plateforme compose le message avec l’identité et la présentation configurées dans Salesforce :

• Expéditeur — utilisateur d’exécution ou adresse e-mail admissible de l’organisation.
• Signature — signature Salesforce de cet utilisateur, sinon signature comprenant son nom, son rôle et son adresse e-mail.
• Destinataire — adresse choisie par l’agent. La plateforme recherche d’abord un contact, puis un prospect non converti, et associe le premier résultat accessible pour le suivi des activités.
• Historique des activités — l’envoi demande l’enregistrement d’une activité, associée au destinataire trouvé et à l’enregistrement concerné lorsque ces relations sont disponibles et valides.
• Identité visuelle — si l’agent est lié à un enregistrement actif de Marque, le message est envoyé en HTML avec votre identité visuelle : logo, couleurs, en-tête, signature et pied de page, accompagnés d’une version texte. Sinon, il reste en texte brut.

Configurer l’adresse e-mail de l’organisation

Sans adresse admissible de l’organisation, l’envoi utilise l’utilisateur d’exécution. Pour présenter une identité cohérente, configurez une adresse e-mail de l’organisation :

Avec une seule adresse admissible autorisée pour tous les profils, la sélection par défaut utilise cette adresse. L’envoi reste soumis à sa vérification et aux règles Salesforce.

Choisir l’expéditeur et l’adresse de réponse

Les instructions de l’agent peuvent préciser l’identité d’envoi et l’adresse de réception des réponses. Un même agent peut ainsi répondre pour plusieurs équipes : une question de facturation depuis billing@, une demande de location depuis leasing@, par exemple.

Les instructions guident le choix de ces paramètres par e-mail. Décrivez quelle identité correspond à chaque type de message, puis vérifiez les paramètres effectivement transmis et le résultat d’envoi.

Lorsqu’une adresse ne correspond pas

Une identité demandée introuvable peut conduire à l’utilisation de l’expéditeur par défaut. Cela ne garantit pas l’envoi : la validation de l’adresse et les erreurs Salesforce continuent de s’appliquer.

• Si l’adresse d’expédition demandée ne correspond pas à une adresse admissible, la plateforme tente l’envoi avec l’identité par défaut et consigne l’absence de correspondance.
• Une adresse de réponse non reconnue comme routable est signalée. Elle peut néanmoins être appliquée si son format est accepté ; vérifiez donc qu’elle reçoit les messages et déclenche le traitement attendu.

Examinez ces avertissements pour comprendre une identité d’envoi inattendue ou un suivi des réponses défaillant.

Renseigner vos propres champs sur l’e-mail

Après l’envoi, la plateforme recherche l’enregistrement EmailMessage correspondant. Si vous avez ajouté des champs personnalisés — catégorie de contact, code de campagne ou indicateur de service — l’agent peut demander leur renseignement. Indiquez dans ses instructions le champ et la valeur attendus ; l’outil les transmet avec l’envoi. Vérifiez le résultat, car l’enregistrement du message n’est pas toujours retrouvable.

Seuls les champs personnalisés dont le nom se termine par __c sont autorisés par ce mécanisme. Les champs standard, tels que l’objet ou l’adresse d’expédition, restent gérés par l’envoi. Les noms sont vérifiés dans le schéma ; les champs inconnus ou non modifiables sont ignorés et leur résultat est renvoyé à l’agent. Un échec de cette mise à jour ne signifie pas que l’e-mail déjà envoyé a été annulé. Consultez Référence des outils intégrés pour les entrées détaillées.

Recherche du destinataire et historique des activités

La plateforme cherche le premier contact accessible correspondant à l’adresse, puis, à défaut, le premier prospect non converti. Elle associe ce résultat à l’enregistrement EmailMessage lorsque Salesforce le permet, ainsi qu’à l’enregistrement fourni dans related_to_id.

Cette recherche ne vérifie pas l’unicité : plusieurs fiches partageant la même adresse peuvent conduire à une association inattendue. Sans résultat accessible, l’envoi peut réussir sans fiche destinataire associée. Utilisez soql_query pour examiner les correspondances avant l’envoi et corrigez les doublons dans les données ; cette recherche préalable ne remplace pas la règle de sélection interne.

Suivi des réponses avec une clé de groupe

Une clé commune permet d’associer un envoi à des actions en attente de réponse et à des suivis temporisés. L’agent doit créer les actions à suivre avant l’envoi pour que celui-ci puisse les relier :

Le suivi s’appuie sur une infrastructure de réception Salesforce, souvent Email-to-Case ou une autre configuration qui capture les réponses comme EmailMessage. Le package utilise des requêtes dynamiques pour rester compatible avec les organisations où cette infrastructure n’est pas activée.

Suivi, limites et gouvernance

• Les limites de messagerie Salesforce s’appliquent. Les plafonds applicables à l’envoi Apex, la délivrabilité et la gestion des rejets restent gouvernés par Salesforce.
• La recherche du destinataire utilise le mode utilisateur. Si les contacts ou prospects ne sont pas accessibles, la résolution peut échouer et l’envoi se poursuivre sans association à une fiche.
• Traçabilité. Consultez les activités et EmailMessage créés selon votre configuration Salesforce, ainsi que les conversations et messages REDA AI. Ne supposez pas qu’une association d’activité manquante signifie que l’envoi a échoué.
• Confirmation des actions. Le canal interne peut demander une confirmation selon la configuration de l’outil. Les canaux externes et automatisés appliquent leur mode d’exécution sans carte.
• Résultats d’erreur. Un échec d’envoi renvoie une erreur structurée à l’agent, qui peut la présenter, demander une correction ou décider d’une nouvelle tentative selon ses instructions.

Bonnes pratiques

Vérifiez le destinataire avant l’envoi. Une requête sur les contacts et prospects permet de détecter les doublons et les associations ambiguës. Maintenez des adresses cohérentes pour fiabiliser l’historique des activités.

Renseignez related_to_id lorsqu’un contexte existe. Pour une opportunité ou une requête, transmettez l’identifiant dans related_to_id, puis vérifiez que Salesforce accepte la relation et enregistre l’activité attendue.

Utilisez group_key pour les suivis associés. Le suivi des réponses et les actions du même échange doivent partager une valeur group_key cohérente. L’identifiant de conversation peut convenir.

Configurez une adresse de l’organisation pour la production. Une adresse vérifiée et correctement configurée permet de conserver une identité d’expédition cohérente.

Vérifiez le mode d’exécution. Dans le canal interne, la confirmation permet de relire le brouillon. Pour les traitements sans carte, limitez les outils, les destinataires et les opérations autorisées au besoin du canal.

Encadrez les agents autonomes. Définissez le ton et le modèle attendus dans leurs instructions. Si des restrictions doivent être garanties, utilisez un outil sortant personnalisé qui valide explicitement le contenu et les destinataires ; un prompt seul ne constitue pas un contrôle d’accès.

Actions d’e-mail, d’enregistrement et de planification

Les actions d’e-mail distinguent le destinataire Contact ou Piste de l’enregistrement métier associé, acceptent des listes À/Cc et vérifient les cas de refus d’e-mail pris en charge. Un Contact/Piste fourni comme enregistrement associé est traité comme destinataire. Les confirmations montrent les champs non appliqués. Les étapes du plan sont rapprochées une à une et les heures relatives conservent UTC. Les agents désactivés et actions imbriquées non autorisées sont vérifiés avant confirmation. La confirmation de liaison de fichiers réutilise le chemin avec contrôle d’accès. Les nouvelles actions horaires en attente ou replanifiées exigent un processeur disponible ; suivi des réponses et mises à jour normales d’historique/statut restent valides. Les travaux différés utilisent leur propriétaire de planification, sans usurper le demandeur. Les instructions réduisent les doublons via d’autres connecteurs, sans garantir le comportement de l’assistant.

Questions fréquentes

Étapes suivantes

Consultez Traitement des réponses par e-mail pour le suivi entrant, ou Actions planifiées pour les envois différés et les déclenchements sur réponse.