Intégration des canaux de messagerie

Ce que couvre cette page

Cette page décrit un principe d’intégration transversal, et non un connecteur propre à un produit. Elle explique :

• Comment un Flow créé par le client transforme les messages entrants d’un système de messagerie en conversations REDA AI
• Comment un outil Apex sortant personnalisé permet à l’agent de répondre par ce même système
• Comment configurer l’agent pour qu’il adapte ses réponses au canal de messagerie plutôt qu’à l’interface Salesforce habituelle

Les connecteurs spécialisés, par exemple REDA Connect pour WhatsApp/SMS ou les passerelles tierces, sont fournis séparément. Ils s’appuient sur les points d’extension décrits ici.

Une liaison dans les deux sens

Toute intégration de messagerie comporte deux parties :

Entrant : du message à l’agent

L’action invocable

REDA AI expose une action Apex invocable utilisable dans un Flow. Elle reçoit le message de l’utilisateur et un enregistrement de contexte, puis renvoie la réponse ou un identifiant de suivi asynchrone.

L’action invocable renvoie les sorties suivantes ; vérifiez le mode asynchrone avant d’envoyer la réponse finale :

Raccorder le Flow entrant

Sortant : de l’agent à l’utilisateur

Pour les messages initiés par l’agent — rappels, suivis, diffusions ou réponses liées à une action — créez un outil de classe Apex qui envoie les messages par votre système. L’agent l’utilise comme tout autre outil.

Ce que l’outil doit définir

• Une description claire, qui permet à l’agent de déterminer quand l’utiliser. Précisez explicitement que l’outil envoie un message par ce canal et quels types de messages conviennent.
• Un schéma d’entrée couvrant l’identifiant du destinataire — numéro de téléphone, identifiant de canal ou de conversation — et le corps du message, ainsi que les options prises en charge par le fournisseur : nom du modèle, langue ou identifiant de pièce jointe.
• Une catégorie Action. L’envoi produit un effet externe. Le canal API ne dispose pas de cartes de confirmation et peut exécuter les actions automatiquement ; limitez donc l’outil aux envois autorisés.
• Des canaux incluant celui de la conversation : un outil situé hors de ce périmètre ne se charge pas.

Dans l’exécuteur

La classe implémente l’interface standard d’exécution des outils et réalise l’opération nécessaire à l’envoi :

• Appel HTTP direct à l’API du fournisseur de messagerie ;
• Opération DML sur l’objet des messages sortants de l’application ;
• Publication d’un événement de plateforme auquel l’application de messagerie est abonnée.

Renvoyez une Map<String, Object> contenant success, message et, si disponible, l’identifiant du message chez le fournisseur. Consultez Outils de classe Apex pour le contrat complet de l’exécuteur.

Configurer l’agent

Deux réglages, sur l’agent et dans l’appel Flow, sont essentiels à l’intégration :

• Canal — choisissez API sur la définition de l’agent. La plateforme sait ainsi que l’agent est piloté par Flow et utilise ce canal pour sélectionner les outils et les prompts applicables.
• Auto-Execute Actions — cette entrée de l’action Flow contrôle le traitement des propositions encore en attente. Le service peut déjà exécuter les actions API ou automatisées ; ne considérez pas cette entrée comme un verrou global. Limitez et validez les outils disponibles, y compris l’outil d’envoi.

Les outils, dont votre outil d’envoi, doivent être disponibles pour cet agent selon leur portée et leur configuration, et inclure API dans leurs canaux. Consultez Configurer les paramètres de l’agent pour la configuration complète.

Fichiers et pièces jointes

Lorsqu’un message entrant contient une pièce jointe, stockez-la comme ContentVersion liée à la conversation ou à un enregistrement accessible à l’utilisateur d’exécution, puis transmettez son identifiant dans fileContentVersionId. L’agent utilise le traitement de fichiers commun aux canaux ; consultez Traitement des documents.

Les pièces jointes sortantes dépendent du fournisseur. Beaucoup acceptent une URL publique ou un identifiant de média. Dans l’exécuteur, créez si nécessaire une URL ContentDistribution de courte durée, ou chargez le fichier chez le fournisseur avant l’envoi. Vérifiez que ce mode de partage convient aux données concernées.

Réponses asynchrones

Une conversation simple peut recevoir sa réponse dans le même appel. Pour le traitement de fichiers volumineux ou une longue série d’outils, la plateforme peut définir isAsync sur true et renvoyer immédiatement un asyncRequestId.

L’intégration dispose alors de deux possibilités :

• Envoyer immédiatement un message d’attente, puis surveiller la requête asynchrone et transmettre la réponse finale à son achèvement.
• Traiter le résultat asynchrone comme un message sortant distinct : un Flow déclenché sur l’objet de requête asynchrone envoie la réponse lorsque la requête atteint son état final. Prévoyez aussi le cas d’échec.

Sécurité et gouvernance

• Choisissez soigneusement l’utilisateur d’exécution. Le contexte du Flow et le mode d’exécution configuré déterminent l’accès aux données des outils intégrés. Pour une messagerie desservant plusieurs utilisateurs, utilisez un utilisateur d’intégration dédié avec des autorisations limitées et contrôlez à quels dossiers chaque expéditeur peut accéder.
• L’outil sortant relève de votre code. Le cadre ne garantit pas le partage et la sécurité des champs dans votre exécuteur personnalisé. Déclarez la classe with sharing, appliquez les contrôles d’objet et de champ nécessaires et validez le destinataire : le modèle ne doit pas pouvoir choisir librement n’importe quel numéro.
• Le limiteur externe ne s’applique pas au canal API. Le limiteur du widget concerne le trafic externe et communautaire. Les appels Flow restent soumis aux limites Salesforce et à la régulation que vous ajoutez à votre messagerie. Prévoyez le traitement des arrivées en nombre.
• Chaque invocation consomme des crédits. Les appels sont décomptés des crédits mensuels de l’organisation. En cas d’épuisement, gérez l’erreur en renvoyant une réponse de secours statique.
• Traçabilité. Les échanges sont enregistrés dans une conversation existante lorsque son identifiant est retransmis, ou dans une nouvelle conversation si nécessaire. L’entrée automatedSource permet d’indiquer le Flow d’origine pour le filtrage et les rapports.

Bonnes pratiques

Conservez le conversationId. Sans cet identifiant, chaque message entrant peut démarrer une nouvelle conversation et l’agent perd le contexte des échanges précédents.

Associez un véritable enregistrement Salesforce au contexte. L’enregistrement de conversation de votre messagerie, le contact correspondant ou un dossier métier associé peuvent convenir. Choisissez celui qui apporte les informations utiles, après avoir vérifié le lien avec l’expéditeur.

Utilisez un agent dédié au canal. Prévoyez un agent distinct de celui de l’interface Salesforce interne : le ton, les prompts et les outils nécessaires diffèrent selon le canal.

Limitez les outils disponibles. Un agent de messagerie a généralement besoin d’outils de lecture et d’un outil d’envoi. Accordez uniquement les actions nécessaires et explicitement autorisées : aucune carte de confirmation n’est disponible dans ce fil de discussion.

Présentez les erreurs de façon adaptée. Si success vaut false, envoyez une réponse de secours compréhensible, par exemple « Je rencontre une difficulté. Veuillez réessayer dans quelques minutes. », plutôt que la valeur brute de errorMessage.

Questions fréquentes

Étapes suivantes

Consultez Outils de classe Apex pour le contrat d’exécution côté sortant, ou Appeler REDA AI depuis des Flows pour l’action invocable côté entrant.