Digital Engagement, Agentforce y el humano: cómo viaja realmente una conversación dentro de Salesforce

Este documento está escrito para dos perfiles: el administrador Salesforce que va a configurar los canales, la cola, las Actions y los permission sets; y el arquitecto que necesita entender los contratos, los objetos y los límites para diseñar una experiencia sostenible. Lo llevamos desde cero — qué es realmente Digital Engagement — hasta el detalle de cómo se ejecuta el handoff a un agente humano sin perder el contexto de la conversación.

Digital Engagement es el add-on de Service Cloud que convierte a Salesforce en el punto donde convergen los canales conversacionales de un cliente empresarial. No es un producto único: es la unión de tres capas que un admin necesita reconocer por separado para saber dónde tocar cuando algo falla.

Qué cambió en 2025–2026

• Agentforce reemplazó a Einstein Bots como el motor conversacional recomendado para nuevas implementaciones. Los bots siguen vigentes en orgs existentes, pero la inversión de plataforma va a Agentforce.
• Enhanced Conversation Components — el Service Console rediseñado — hace que un humano vea sesiones de cualquier canal (chat, WhatsApp, voz, Apple) con la misma UI y el mismo historial persistente.
• Agent Handoff se estandarizó como una Action nativa: el mismo agente decide cuándo transferir, y Omni-Channel rutea al humano con la sesión abierta.
• Service Cloud Voice sumó Agentforce Voice — un agente conversacional de voz nativo — que sigue el mismo modelo de sesiones + Omni-Channel que los canales de mensajería.
• Data Cloud entró como capa de grounding: el agente conversacional puede leer perfil unificado en tiempo real durante la conversación, no solo consultar SObjects.

Antes de seguir hace falta un glosario operativo. Todos estos son objetos y configuraciones reales que verá en Setup o al inspeccionar registros — no son abstracciones de arquitectura. Si su equipo no comparte este vocabulario, cualquier discusión de troubleshooting se vuelve imposible.

Diferencia crítica: Agentforce vs Einstein Bots

Cada canal tiene reglas propias que un admin debe conocer antes de tocar Setup. Todos convergen en el mismo objeto MessagingSession — pero lo que ocurre antes de esa sesión difiere. Aquí un recorrido con el nivel de detalle suficiente para configurarlos, más profundidad en WhatsApp, Web y Voz porque son los más comunes en LATAM.

WhatsApp Business Platform

El canal más pedido en LATAM. Meta es el provider oficial (Cloud API o BSP). Salesforce no habla con el número del cliente: habla con la WhatsApp Business Account de Meta. Cada línea configurada en Salesforce es un MessagingChannel apuntando a un phone number ID en Meta.

• Ventana de 24 horas: mientras el cliente responda en los últimos 24 h, cualquier mensaje libre está permitido. Fuera de ventana, solo plantillas HSM aprobadas por Meta pueden abrir sesión.
• Templates (HSM): mensajes pre-aprobados por Meta con variables. Se envían con Enhanced Messaging Template. Sin plantilla aprobada, no hay outbound proactivo.
• Media inbound: imagen, video, documento, audio, sticker, ubicación, contacto. Salesforce los guarda como ContentVersion ligados al ConversationEntry.
• Interactivos: buttons, list messages, quick replies. El agente (humano o Agentforce) puede enviarlos vía Enhanced Messaging Components.
• Consentimiento: el cliente inició la conversación o hay opt-in explícito registrado. Sin eso, Meta bloquea o penaliza el número.

Messaging for In-App and Web (MIAW)

El canal del propio sitio o app del cliente. A diferencia del Embedded Chat viejo, MIAW crea MessagingSession real, persiste ConversationEntry y sobrevive a recargas de página. Es lo que un admin debe configurar hoy — no el Embedded Chat legacy.

• Embedded Service Deployment: el snippet JS que se pega en el sitio. Define look & feel, pre-chat form (opcional), auth JWT (opcional).
• MessagingChannel de tipo Custom Client Web/App: se enlaza al deployment.
• Autenticación: anónimo (visitante no logueado) o autenticado con JWT firmado por el sitio del cliente (identifica al Contact desde el primer mensaje).
• Rich content: file upload, image, botones inline, choices, forms, typing indicators.
• Persistencia: si el usuario recarga y vuelve, la misma MessagingSession se reanuda si sigue Active y el JWT resuelve al mismo endUser.

Apple Messages for Business

El cliente inicia la conversación desde Mapas, Safari o el sitio del negocio (nunca al revés — Apple prohíbe outreach). Rich features únicas: Apple Pay, list picker, time picker, form. La configuración requiere registro previo en Apple Register.

Facebook Messenger

Ligado a una Facebook Page. Similares reglas de ventana (24h) e interactivos. Ideal cuando la marca tiene presencia fuerte en Facebook y el cliente joven no usa WhatsApp.

SMS

El canal universal. Salesforce se integra con proveedores (LINK Mobility u otros vía connector). No hay rich content estándar: solo texto y links. Óptimo para OTP, alertas de estado y outreach masivo con opt-in.

Service Cloud Voice (SCV)

Voz — llamada telefónica — como canal nativo. Convive con Digital Engagement bajo el mismo paradigma: hay una sesión de voz (VoiceCall) ligada a una MessagingSession compañera cuando el agente conversacional participa. Dos sabores de despliegue.

Tabla resumen por canal

Vamos a seguir un mensaje real desde que el cliente presiona enviar hasta que Salesforce tiene todos sus objetos abiertos y listos para ser atendidos. Este es el circuito que un admin debería conocer de memoria: es el 80% de los tickets de soporte que va a levantar cuando algo no se comporte como esperaba.

   ┌───────────────┐
   │  Cliente      │  Envía: "Hola, necesito ayuda con mi pedido."
   │  (WhatsApp)   │
   └───────┬───────┘
           │  ①  App/red móvil
           ▼
   ┌──────────────────────────────────────────────┐
   │  Meta · WhatsApp Business Platform           │
   │  · Verifica que el número esté registrado    │
   │  · Aplica reglas de ventana 24h              │
   └───────┬──────────────────────────────────────┘
           │  ②  Webhook HTTPS con payload firmado
           ▼
   ┌──────────────────────────────────────────────┐
   │  DIGITAL ENGAGEMENT · Inbound Gateway        │
   │  · Valida firma y MessagingChannel activo    │
   │  · Resuelve MessagingEndUser (crea si falta) │
   │  · Abre/reanuda MessagingSession             │
   │  · Persiste ConversationEntry (el texto)     │
   └───────┬──────────────────────────────────────┘
           │  ③  Trigger de Omni-Channel Flow
           ▼
   ┌──────────────────────────────────────────────┐
   │  OMNI-CHANNEL FLOW (Route Work)              │
   │  ¿Hay Agentforce Agent para este canal?      │
   │  ¿Filtros de negocio (VIP, horario, país)?   │
   │  → Decide: Agentforce  vs  Cola humana       │
   └─┬─────────────────────────────────┬──────────┘
     │ Sí                              │ No / regla
     ▼                                 ▼
   ┌────────────────────┐         ┌──────────────────┐
   │  AGENTFORCE AGENT  │         │  QUEUE + PRESENCE│
   │  · Reasoning Engine│         │  Humano toma vía │
   │  · Topics + Actions│         │  Omni Widget     │
   │  · Data Cloud RAG  │         └──────────────────┘
   └─────────┬──────────┘
             │  ④  Responde ConversationEntry outbound
             ▼
   ┌──────────────────────────────────────────────┐
   │  DIGITAL ENGAGEMENT · Outbound Gateway       │
   │  · Aplica plantilla si aplica                │
   │  · Serializa a payload Meta                  │
   └───────┬──────────────────────────────────────┘
           │  ⑤  HTTPS a Meta → app del cliente
           ▼
   ┌───────────────┐
   │  Cliente ve   │  Respuesta del agente
   │  la respuesta │
   └───────────────┘

Los cinco pasos desglosados

1. Provider recibe el mensaje. Meta valida su propio contrato: número activo, no bloqueado, dentro de ventana o plantilla. Si algo falla aquí, Salesforce nunca se entera — el mensaje se pierde en Meta.
2. Provider dispara webhook a Salesforce. Payload firmado con el App Secret. Digital Engagement rechaza cualquier request cuya firma no valide. Un admin puede confirmar esto en Setup → Messaging Settings → Channel Health.
3. Digital Engagement traduce a objetos Salesforce. Este es el paso más importante. Aquí se crean/reanudan tres registros: MessagingEndUser (uno por número/cliente), MessagingSession (una por conversación activa) y ConversationEntry (uno por mensaje). El status de la MessagingSession pasa a ‘In Progress’.
4. Omni-Channel Flow decide el destino. El flow tipo Route Work se dispara con la MessagingSession como registro objetivo. Puede rutear a un Agentforce Agent (asigna owner al usuario del agente), a una cola humana, o a una skill específica.
5. Respuesta outbound. Cuando Agentforce o el humano contesta, el texto se persiste como ConversationEntry (Direction = Outbound) y Digital Engagement lo empuja al provider. El provider lo entrega al cliente. Todo esto persistido en el mismo hilo, buscable, auditable.

Qué pasa cuando algo falla

Agentforce no entra solo. Entra porque el Omni-Channel Flow decidió rutear la sesión a su usuario. Ese detalle importa: si su flow no está configurado para asignar el owner al Agentforce user, el agente simplemente nunca ve la conversación. Esta sección explica qué hace el agente una vez que sí recibe la sesión.

   ┌─────────────────────────────────────────────────────────┐
   │  MessagingSession asignada al Agentforce Agent          │
   └─────────────────┬───────────────────────────────────────┘
                     │  Nuevo ConversationEntry inbound
                     ▼
   ┌─────────────────────────────────────────────────────────┐
   │  REASONING ENGINE (Atlas)                               │
   │  ①  Lee el mensaje + historial + contexto de Data Cloud │
   │  ②  Recorre Topics activos → elige el más pertinente    │
   │  ③  Decide: ¿respondo directo? ¿invoco Action?          │
   │     ¿pido más info? ¿hago handoff?                      │
   └─┬───────────────┬────────────────┬────────────────┬─────┘
     │               │                │                │
     ▼               ▼                ▼                ▼
   ┌────────┐  ┌───────────┐  ┌──────────────┐  ┌───────────┐
   │ Prompt │  │ Flow      │  │ Apex         │  │ Handoff   │
   │ Templ. │  │ Action    │  │ Invocable    │  │ Action    │
   │ (redac)│  │(negocio)  │  │(complejo)    │  │(→ humano) │
   └────┬───┘  └─────┬─────┘  └──────┬───────┘  └─────┬─────┘
        │            │               │                │
        └────────────┴───────────────┴────────────────┘
                          │
                          ▼
              Respuesta persistida como
              ConversationEntry outbound

Qué es un Topic

Un Topic es un dominio de conversación. Piense en él como la ‘especialidad’ que el agente sabe manejar. Cada topic tiene: un scope (cuándo aplica), instrucciones (cómo comportarse dentro), y un set de Actions disponibles (qué puede invocar). Un agente típico de servicio en un banco tendría topics como ‘Consulta de saldo’, ‘Reporte de transacción sospechosa’, ‘Cambio de datos de contacto’ y ‘Escalamiento a asesor’.

Qué son las Actions

Las Actions son las manos del agente. Sin ellas, Agentforce es un chatbot elegante que solo habla. Cada Action tiene inputs, outputs, descripción semántica (que el Reasoning Engine lee para decidir cuándo usarla) y un implementador — Flow, Apex, Prompt Template, External Service, MCP tool.

• Flow Action: la más recomendada cuando la lógica ya vive en Salesforce y hay reglas declarativas. Ejemplo: ‘Actualizar dirección del contacto’ con validaciones y ownership.
• Apex Invocable Action: cuando la lógica es compleja, requiere SOQL avanzado, DML transaccional o llamadas coordinadas. Ejemplo: ‘Cotización dinámica con reglas de pricing’.
• Prompt Template Action: cuando el output es texto generado con contexto CRM. Ejemplo: ‘Resumir historial de casos del cliente en tres bullets’.
• External Service / API: cuando el dato vive fuera. Con Named Credential + OpenAPI. Ejemplo: ‘Consultar estado de envío en el WMS externo’.
• MCP Tool: fuente externa estandarizada. Ejemplo: ‘Buscar documento en el knowledge base corporativo’.
• Data Cloud Query: perfil unificado en tiempo real. Ejemplo: ‘Traer últimos 5 eventos de web + email + app del cliente antes de responder’.

Data Cloud como grounding en vivo

Cuando Data Cloud está enlazado al agente, cada turno puede consultar el perfil unificado del cliente sin escribir código explícito — el Reasoning Engine decide si consultarlo según el contexto. Esto es lo que diferencia una respuesta genérica de una respuesta con conocimiento: ‘Su último caso fue hace 3 días sobre el mismo tema, y sigue sin resolverse’. Sin Data Cloud, eso requeriría una Action explícita para cada consulta; con Data Cloud, es contexto ambiente.

Convivencia con Digital Engagement

Agentforce nunca sustituye a Digital Engagement. Trabajan en capas distintas: Digital Engagement mantiene la sesión viva, respeta la ventana del canal, aplica plantillas, persiste cada entry y garantiza que el cliente vea la respuesta en el canal correcto. Agentforce decide qué decir. Si Digital Engagement no está, Agentforce no ve nada; si Agentforce no está, Digital Engagement funciona igual pero sin razonamiento — solo humano o bot legacy. Los dos productos se complementan; no compiten.

El handoff es donde más despliegues fallan. No porque la tecnología no lo soporte — lo soporta bien — sino porque se configura sin diseñar el momento humano detrás. Un handoff bien hecho no interrumpe al cliente, preserva el contexto y despierta al humano correcto en menos de un minuto. Un handoff mal hecho deja al cliente en silencio, hace que el humano lea de cero, o pega el mensaje en una cola sin quien lo tome. Vamos a verlo paso a paso.

Quién decide el handoff

• El agente Agentforce decide cuando el Reasoning Engine concluye que la conversación excede su alcance (tema fuera de topics, límite de intentos, señal de frustración del cliente, criterio de negocio explícito).
• El cliente decide cuando pide hablar con un humano — ese pedido es una intención que el agente reconoce y ejecuta como Handoff Action.
• Un evento externo decide — por ejemplo, un valor de VIP detectado en Data Cloud dispara auto-escalamiento sin esperar al Reasoning Engine.
• Un timeout decide — X turnos sin resolver, escalamiento forzado a humano para no dejar al cliente frustrado.

   ┌──────────────────────────────────────┐
   │ AGENTFORCE detecta necesidad handoff │
   └───────────────┬──────────────────────┘
                   │  Invoca "Agent Handoff Action"
                   ▼
   ┌──────────────────────────────────────┐
   │ HANDOFF ACTION                       │
   │ · Publica reason y summary           │
   │ · Cambia MessagingSession.Owner      │
   │ · Dispara Omni-Channel Route         │
   └───────────────┬──────────────────────┘
                   │
                   ▼
   ┌──────────────────────────────────────┐
   │ OMNI-CHANNEL                         │
   │ · Cola destino (skill, país, tier)   │
   │ · Presence del humano disponible     │
   │ · Push notification al Omni Widget   │
   └───────────────┬──────────────────────┘
                   │  Humano acepta
                   ▼
   ┌──────────────────────────────────────┐
   │ AGENTE HUMANO · Enhanced Console     │
   │ · Ve historial completo              │
   │ · Ve resumen del agente              │
   │ · Ve perfil, casos, órdenes          │
   │ · Continúa la conversación en vivo   │
   └──────────────────────────────────────┘

Qué se preserva en el handoff

• El historial completo de ConversationEntry — el humano ve cada mensaje textual del cliente y del agente.
• El resumen que el agente publica en la Handoff Action — típicamente 2–3 frases con el problema, lo que ya se intentó y el motivo del handoff.
• Todo el contexto CRM enlazado a la MessagingSession — Contact, Cases, Orders relevantes, actividad de Data Cloud.
• Los archivos adjuntos (imágenes, PDFs) que el cliente compartió durante la sesión con el agente.
• El mismo canal — el cliente sigue conversando en WhatsApp/Web/Voz sin percibir la transición.
• El status del cliente en el canal (typing, delivered, read) — no se rompe la experiencia visual.

Qué configura el admin para que el handoff funcione

El regreso al agente (‘bot-back’)

El handoff no siempre es unidireccional. Un humano puede regresar la sesión al Agentforce Agent — típicamente después de resolver el punto que requería criterio humano. La sesión vuelve al agente con el owner cambiado y el agente continúa la conversación con el mismo canal, historial y contexto. Esta capacidad se llama ‘bot-back’ o ‘re-engage’ y evita que el humano tenga que sostener una conversación completa después del pico crítico.

Este diagrama junta las seis piezas — canal, Digital Engagement, Omni-Channel, Agentforce, Data Cloud, humano — en un solo plano. Úselo como base para dibujar la implementación específica de su cliente y para mapear qué pieza toca cada equipo durante el proyecto.

┌──────────────────────────────────────────────────────────────────────────┐
│  CANALES EXTERNOS                                                        │
│  WhatsApp · MIAW Web/App · Apple · Messenger · SMS · Voice (SCV)         │
└─────────────────────────────────┬────────────────────────────────────────┘
                                  │  Webhooks / RTC / SDK
                                  ▼
┌──────────────────────────────────────────────────────────────────────────┐
│  DIGITAL ENGAGEMENT                                                      │
│  · MessagingChannel · MessagingEndUser · MessagingSession                │
│  · ConversationEntry · Templates HSM · Consent / opt-in                  │
│  · Enhanced Messaging Components (UI del console)                        │
└──────────────────────┬───────────────────────────────────────────────────┘
                       │  Omni-Channel Flow (Route Work)
                       ▼
┌──────────────────────────────────────────────────────────────────────────┐
│  OMNI-CHANNEL                                                            │
│  · Service Channels · Queues · Skills · Presence · Routing rules         │
└─┬─────────────────────────┬───────────────────────────┬──────────────────┘
  │ Ruta A                  │ Ruta B                    │ Ruta C
  ▼                         ▼                           ▼
┌──────────────┐   ┌────────────────────┐   ┌──────────────────────────┐
│ AGENTFORCE   │   │ EINSTEIN BOT       │   │ HUMANO                   │
│ · Reasoning  │   │ (legacy si aplica) │   │ · Enhanced Console       │
│ · Topics     │   └────────────────────┘   │ · Presence + capacidad   │
│ · Actions    │                            │ · Wrap-up + Cases        │
│ · Grounding  │                            └──────────────────────────┘
└──────┬───────┘         ▲                             ▲
       │                 │                             │
       │  Handoff Action │  Bot-back                   │
       └─────────────────┴─────────────────────────────┘

┌──────────────────────────────────────────────────────────────────────────┐
│  DATA CLOUD · Perfil unificado · Grounding en tiempo real                │
│  Consumido por Agentforce y visible en el Console para humanos           │
└──────────────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────────────┐
│  GOVERNANCE / OBSERVABILIDAD                                             │
│  Einstein Trust Layer · Audit · PII masking · Consent · Retention        │
│  Session Analytics · Agent Metrics · Wrap-up / disposition               │
└──────────────────────────────────────────────────────────────────────────┘

• Todos los canales convergen en Digital Engagement — no hay atajos que salten esa capa.
• Omni-Channel es el conmutador único: decide adónde va la sesión (Agentforce, bot legacy o humano).
• Agentforce y humano viven al mismo nivel — no hay jerarquía, solo cambio de owner de la MessagingSession.
• Data Cloud da grounding tanto al agente conversacional como al humano en el console.
• El governance layer aplica transversalmente — masking de PII, retención de conversaciones, audit trail.

Esta es la secuencia práctica que evita re-trabajo. Cada paso desbloquea el siguiente — saltarlo obliga a volver atrás. La cursa entera para un despliegue nuevo va de 3 a 6 semanas si no hay bloqueos externos (aprobaciones de Meta, contratos con partners de telefonía).

1. Activar Digital Engagement en Setup → Company Information (verifique licencias y feature toggle).
2. Asignar permission sets: ‘Service Cloud User’, ‘Digital Engagement User’, y — cuando aplique — ‘Agentforce Service Agent User’ o el que la org tenga para el agente.
3. Configurar Service Channel para Messaging y para Voice (si aplica) en Setup → Omni-Channel Service Channels.
4. Crear la Queue destino para handoff humano. Definir a qué usuarios rutea y su capacidad por sesión.
5. Configurar Presence Statuses y Presence Configurations. Un humano típico maneja 2–4 sesiones concurrentes de messaging + 1 llamada.
6. Registrar el número/página/deployment en el provider externo (WhatsApp Manager, Apple Register, deployment web).
7. Crear el MessagingChannel apuntando al provider. Validar Channel Health.
8. Diseñar el Omni-Channel Flow tipo Route Work: entrada = MessagingSession, ramas = Agentforce vs Queue humana, con criterios de negocio explícitos.
9. Si va a usar Agentforce: crear el agente en Agent Studio con topics, instructions y actions. Publicar y probar en el Preview antes de conectarlo al canal.
10. Añadir la Handoff Action al agente. Configurar su Prompt Template de summary.
11. Validar el Enhanced Messaging Component en el Service Console app — no el chat viejo.
12. Definir Wrap-up: cuándo se crea Case, qué disposición se captura, quién es el owner post-conversación.
13. Configurar retención de conversaciones y consent tracking según su marco regulatorio (GDPR, LFPDPPP MX, LGPD BR, HIPAA).
14. Habilitar Session Analytics + Agent Metrics + Voice Analytics. Sin telemetría, no hay iteración.
15. Piloto en un solo canal con volumen controlado. Escale al segundo canal solo después de validar los ocho pasos anteriores en el primero.

Digital Engagement, Agentforce y el agente humano son tres piezas de un mismo circuito. Ninguna reemplaza a las otras: Digital Engagement traduce y mantiene viva la conversación, Agentforce razona y ejecuta cuando puede, y el humano interviene cuando aporta lo que la máquina no. Todo se orquesta con Omni-Channel y todo persiste en el mismo hilo de objetos Salesforce que un admin puede auditar y depurar.

La calidad de un despliegue no se ve en el diagrama, se ve en tres momentos concretos. Uno: cuando el cliente escribe la primera vez y ve respuesta en menos de tres segundos. Dos: cuando Agentforce reconoce su límite e invoca handoff con un summary claro. Tres: cuando el humano toma la sesión y sigue la conversación sin que el cliente perciba la transición. Si esos tres momentos funcionan, el resto es iteración fina.

Documentación vigente para profundizar en cada capa. Las APIs y features evolucionan rápido — valide siempre con la versión de release actual antes de comprometer arquitectura o timelines.

• Salesforce Digital Engagement — visión general
• Messaging for In-App and Web (MIAW) · Salesforce Help
• Messaging Channels (WhatsApp, Apple, Messenger, SMS) · Help
• MessagingSession · SObject Reference
• ConversationEntry · SObject Reference
• Omni-Channel · Setup y Routing
• Agentforce · Building Service Agents (Developer Guide)
• Agent Actions · Salesforce Help
• Service Cloud Voice · Help
• Enhanced Messaging Console Components
• Einstein Trust Layer · Architecture
• Data Cloud · Unified Profile
• Salesforce Architects · Well-Architected Framework