Integración del canal de mensajería

Qué cubre esta página

Este es un patrón de integración horizontal, no un conector para un producto concreto. Explica:

• Cómo un Flujo creado por el cliente convierte los mensajes entrantes de cualquier sistema de mensajería en conversaciones de REDA AI
• Cómo una herramienta de Apex saliente personalizada permite al agente enviar respuestas de vuelta a través de ese mismo sistema
• Cómo configurar el agente para que entienda que está hablando a través de un canal de mensajería en lugar de la interfaz estándar de Salesforce

Los conectores específicos — por ejemplo REDA Connect para WhatsApp/SMS, o pasarelas de terceros — se entregan como paquetes de extensión separados. Cada uno se construye sobre el patrón descrito aquí.

El puente de doble sentido

Cada integración de mensajería tiene dos mitades:

Entrante: del mensaje al agente

El invocable

REDA AI expone una acción de Apex invocable que cualquier Flujo puede llamar. Recibe el mensaje del usuario y un registro de contexto, y devuelve la respuesta del agente.

El invocable devuelve la respuesta del agente de forma síncrona:

Configurar el Flujo entrante

Saliente: del agente al usuario

Para los mensajes iniciados por el agente — avisos, seguimientos, difusiones, respuestas impulsadas por acciones — crea una herramienta de clase Apex que publique en tu sistema de mensajería. El agente la usa como cualquier otra herramienta.

Lo que necesita la herramienta

• Una Descripción clara — así es como el agente decide cuándo usarla. Indica explícitamente que envía un mensaje a través de tu canal y qué tipos de mensaje son apropiados.
• Un Esquema de entrada que cubra el identificador de destino (teléfono, ID de canal, Id de conversación) y el cuerpo del mensaje, además de las opciones que admita tu proveedor (nombre de plantilla, configuración regional, ID de adjunto).
• Una Categoría de Action. Los mensajes salientes tienen efectos secundarios, por lo que el agente mostrará una tarjeta de confirmación de forma predeterminada.
• Unos Canales que incluyan el canal en el que se ejecuta el agente — una herramienta fuera del canal de la conversación nunca se carga.

Dentro del ejecutor

La clase implementa la interfaz estándar de ejecutor de herramientas y hace lo que sea necesario para despachar el mensaje:

• Un callout HTTP directamente a la API del proveedor de mensajería, o
• DML sobre el objeto de mensaje saliente de la app de mensajería, o
• Publicar un Platform Event al que la app de mensajería está suscrita.

Devuelve un Map<String, Object> con success, message y el Id del mensaje del proveedor cuando esté disponible. Consulta Herramientas de clases Apex para conocer el contrato completo del ejecutor.

Configurar el agente

Dos ajustes de la Definición de agente son importantes para las integraciones de mensajería:

• Canal — configúralo en API. Esto le indica a la plataforma que el agente está siendo impulsado por un Flujo y no por una sesión de interfaz, y controla qué herramientas y prompts se cargan para el agente.
• Ejecutar acciones automáticamente — considera habilitarlo. Las tarjetas de confirmación no existen en un canal de mensajería; puedes dejar que el agente ejecute por sí mismo las acciones no destructivas, o limitar el conjunto de herramientas a las de solo lectura y de mensaje saliente.

Las herramientas — incluida la herramienta de mensaje saliente que creaste — deben asignarse al agente e incluir API en su alcance de canal. Consulta Configuración del agente para ver la configuración completa del agente.

Archivos y adjuntos

Cuando un mensaje entrante incluye un adjunto, almacénalo como un ContentVersion en el registro de conversación (o cualquier registro que el usuario pueda leer) y luego pasa su Id como fileContentVersionId al invocable. El agente procesará el archivo con la misma maquinaria que cualquier otro canal — consulta Procesamiento de documentos.

Los adjuntos salientes dependen del proveedor de mensajería. La mayoría de los proveedores aceptan una URL pública o un Id de medio; en el ejecutor de la herramienta saliente, genera una URL de ContentDistribution de corta duración o sube el archivo al proveedor antes de enviarlo.

Respuestas asíncronas

Para la mayoría de las conversaciones de mensajería, la respuesta síncrona funciona bien — llega el mensaje del usuario, el Flujo espera y el agente responde en segundos. Para el procesamiento pesado de archivos o cadenas agénticas largas, la plataforma puede establecer isAsync en true y devolver de inmediato un asyncRequestId.

Cuando eso ocurre, la integración tiene dos opciones:

• Envía de inmediato un mensaje de indicador de escritura y luego vigila la solicitud asíncrona y publica la respuesta final cuando se complete.
• Trata el resultado asíncrono como un mensaje saliente separado: un Flujo activado por registro sobre el objeto de solicitud asíncrona, disparado cuando la solicitud alcanza su estado terminal, publica la respuesta de vuelta al usuario.

Seguridad y gobernanza

• Elige con cuidado el usuario en ejecución. El Flujo se ejecuta en algún contexto de usuario — normalmente el usuario en ejecución del desencadenador entrante. Los permisos de ese usuario determinan qué pueden hacer las herramientas y qué datos ve el agente. Usa un usuario de integración dedicado con un conjunto de permisos ajustado cuando el sistema de mensajería atienda a muchos usuarios.
• Lo saliente es tu código. La plataforma no aplica el uso compartido ni la FLS dentro de tu herramienta saliente — declara la clase with sharing y valida los identificadores de destino (no dejes que el modelo envíe a un número de teléfono arbitrario sin controles).
• No se aplica ningún limitador de frecuencia externo a API. El limitador de frecuencia del widget se aplica al tráfico externo o de comunidad; las invocaciones impulsadas por Flujo dependen de los propios límites reguladores de Salesforce y de cualquier control de flujo que integres en tu sistema de mensajería. Planifica en consecuencia para el tráfico entrante masivo.
• Los créditos se consumen por invocación. Cada llamada al invocable se descuenta de los créditos mensuales de la organización. Si la organización se queda sin créditos, la llamada devuelve un error y la conversación debería recurrir a una respuesta estática.
• Rastro de auditoría. Cada invocación crea un registro de Conversación y de Mensaje; automatedSource en la entrada te permite etiquetar las conversaciones con el nombre del Flujo de origen para filtrar y generar informes.

Prácticas recomendadas

Conserva el conversationId. Sin él, cada mensaje entrante parece el inicio de una conversación nueva y el agente pierde la memoria a mitad del hilo.

Asocia un registro real de Salesforce como contexto. El agente funciona mucho mejor cuando sabe con quién está hablando. El registro de conversación de tu app de mensajería, el Contacto coincidente o un registro de negocio relacionado sirven todos — elige el que tenga la señal más rica.

Usa un agente dedicado para el canal. No reutilices el mismo agente en la interfaz interna de Salesforce y en un canal de mensajería. Los distintos canales necesitan un tono, prompts y conjuntos de herramientas diferentes.

Limita el conjunto de herramientas. Un agente de canal de mensajería normalmente necesita herramientas de lectura y una herramienta de mensaje saliente. Resiste la tentación de darle el conjunto completo de acciones — no puedes mostrar tarjetas de confirmación en un hilo de chat.

Gestiona los errores con elegancia. Si success es false, publica una respuesta alternativa amable (“Estoy teniendo problemas en este momento — inténtalo de nuevo en unos minutos”) en lugar del errorMessage sin procesar.

Preguntas frecuentes

Próximos pasos

Lee Herramientas de clases Apex para conocer el contrato del ejecutor que implementarás en el lado saliente, o Invocar REDA AI desde Flujos para más información sobre el invocable entrante.