Imagina que arrancas la mañana con un café y un mensaje en Slack que ya te dice qué pasó en tus organizaciones de Salesforce durante la noche. Sin abrir reportes ni revisar logs, sabes qué es urgente y qué puede esperar.
Esa es la idea central de la charla en vivo que dieron Francisco Morales (Fran) y Esteban Morales (Esti) en Dreamforce: Design Proactive Agents with Flow, Agentforce, and Slack. Son hermanos y forman parte del equipo de Vantegrate, que trabaja con muchas organizaciones de Salesforce a la vez.
En este artículo te contamos cómo pasar de una IA reactiva a una IA proactiva usando herramientas que probablemente ya conoces. No hace falta reinventar nada: alcanza con combinar bien tres piezas que viven en el ecosistema de Salesforce.
De la IA reactiva a la IA proactiva
Hoy la mayoría usa la IA de forma reactiva. Le escribes una pregunta a un chat, esperas la respuesta y recién ahí actúas.
Fran lo planteó al revés. La propuesta es tener una IA que trabaja para ti durante la noche y te entrega el resultado listo cuando empiezas tu jornada.
La diferencia parece chica, pero cambia todo. Con el modelo reactivo, tú tienes que acordarte de preguntar; con el modelo proactivo, el sistema te avisa lo que importa sin que lo pidas.
Para un equipo que cuida varias organizaciones, esto es oro. Recibir cada mañana un resumen de lo que hay que vigilar durante el día ahorra tiempo y evita sorpresas.
Si quieres entender mejor qué puede hacer un agente en tu empresa, mira nuestra página de agentes de IA. Ahí vas a encontrar el contexto general antes de meterte en el detalle técnico.
El final primero: un resumen diario en Slack
Los hermanos Morales arrancaron la charla por el final. En lugar de mostrar una agenda, mostraron directamente el resultado: un mensaje en Slack generado por un agente.
El mensaje llega todas las mañanas a las 7. Resume el estado de la organización y señala lo que merece atención.
En la demo, el agente indicaba que la mayoría de las cosas estaban bien. Pero también marcaba un problema concreto que había que mirar con lupa.
Ese es el valor real del enfoque. No es un reporte más: es una lista priorizada que separa lo crítico de lo que puede esperar.
La técnica en tres pasos: detectar, razonar y actuar
Fran aclaró que esa era la única parte teórica de la sesión. Todo el resto fue demo.
La técnica tiene tres pasos muy claros:
Detectar: un Schedule Flow se dispara en un momento del día y recoge información.
Razonar: Agentforce usa el conocimiento de tu negocio para entender esa información y decidir qué hacer.
Actuar: con el análisis listo, el sistema envía un mensaje a Slack.
Fran lo definió como un escenario muy sencillo, pero real. Y pidió pensar en todas las posibilidades que abre combinar Slack con Salesforce.
Lo interesante es que cada paso usa una herramienta distinta y conocida. Por eso el enfoque es accesible incluso si recién empiezas con agentes.
Piensa en los tres pasos como una cadena. Si la detección trae datos pobres, el razonamiento falla; si el razonamiento es bueno pero el mensaje llega a destiempo, nadie actúa.
Por eso conviene diseñar las tres partes juntas, desde el principio. Cada eslabón depende del anterior, y el resultado final solo vale si llega a la persona correcta en el momento correcto.
Paso 1: Schedule Flow para detectar
Un Flow es, en pocas palabras, un proceso automatizado dentro de Salesforce. Esti lo explicó así para quienes no lo conocían: es un proceso que corre en el fondo.
El Schedule Flow es un tipo de Flow que se ejecuta en un horario definido. En la demo, corre todos los días a las 7 de la mañana.
Esti remarcó que el primer paso para trabajar de forma proactiva es justamente ese. Tienes que definir cuándo quieres que se ejecute la automatización.
Parece un detalle menor, pero no lo es. El horario determina si el mensaje llega cuando la gente puede leerlo o cuando nadie le presta atención.
Las señales: qué vale la pena vigilar
El siguiente paso del Flow es recolectar señales. Una señal es cualquier dato que te indica que algo cambió y que quizás necesitas actuar.
En la demo, las señales se recolectaban con una clase de Apex. Esti aclaró que lo hicieron así para simplificar, pero que puedes usar cualquier otra fuente que ya tengas en tu Flow.
Las señales que mostraron fueron de tres tipos:
Una métrica que cayó de 40% a 7% en las últimas 24 horas, algo que obviamente quieres entender.
Los límites de API de la organización.
Los cambios de seguridad y de configuración.
Ante una caída así, la pregunta natural es por qué pasó y qué pasó. Ahí entra el segundo paso, donde un agente analiza la información en lugar de que tú lo hagas a mano.
Si te preocupa la parte de seguridad y permisos, te recomendamos leer cómo pensamos la seguridad de la plataforma. Vigilar cambios de acceso es una de las señales más valiosas que puedes elegir.
Paso 2: Agentforce para razonar
Fran insistió en que esta parte era muy importante. Es el momento en que el Flow llama a un agente de Agentforce.
Dentro del Flow se agrega una nueva acción que invoca al agente. Los hermanos tenían muchos agentes definidos, pero usaron uno que ya tenía todas las reglas cargadas.
El agente recibe todo lo que se recolectó en el primer paso. Con esa información, sigue una serie de pasos definidos en sus instrucciones.
Primero decide qué es crítico y qué puede esperar. Después prioriza las señales y busca la próxima mejor acción para cada caso.
Por último, redacta el mensaje que se va a enviar. Todo eso pasa sin que nadie escriba nada en el momento: el Flow le pasa los datos y el agente hace el trabajo.
Este es el corazón del enfoque. El Flow aporta el horario y los datos; el agente aporta el criterio, basado en el conocimiento de tu negocio que le diste en sus reglas.
Si eres desarrollador y quieres profundizar en cómo se construyen estas piezas, visita nuestra sección de Salesforce para desarrolladores. Ahí reunimos recursos para equipos técnicos.
Paso 3: Slack para actuar
Con el análisis listo, el último paso es actuar. En la demo, la acción es enviar un mensaje a un canal de Slack.
Esti mostró el mensaje real que llegó. Resumía el estado general y, a la vez, destacaba lo que no estaba bien.
El ejemplo más fuerte fue un cambio de seguridad. El agente detectó que un usuario había sido promovido de Standard a Admin, algo muy crítico que un administrador tiene que revisar.
Además, el mensaje incluía información sobre otros cambios y automatizaciones de los últimos 7 días. Y marcaba qué ítems había que revisar y quién había hecho cada cambio.
Como dijo Esti, el agente fue lo bastante inteligente para entender esa señal. Es lo mismo que harías tú si revisaras todo a mano, pero sin gastar la primera hora del día.
Lo que aprendieron a los golpes
Fran fue honesto sobre los errores que cometieron. Esa parte de la charla vale tanto como la demo.
El primer error fue querer usarlo en cualquier situación. Cuando entendieron cómo funcionaba, empezaron a repetirlo e intentaron capturar cada señal posible.
Eso los llevó a chocar con los límites del sistema. La lección es clara: tienes que entender qué patrones y qué señales son útiles para tu negocio, no vigilar todo.
Cuándo no usar un Schedule Flow
Hay escenarios donde esperar al día siguiente no tiene sentido. El Flow de la demo corre una vez por día, y eso no sirve si algo necesita respuesta inmediata.
Para esos casos, Fran recomendó usar un trigger en lugar del Schedule Flow. Así el mensaje sale en el momento en que ocurre el evento.
La regla práctica es simple. Si la señal puede esperar unas horas, el resumen diario alcanza; si no puede esperar, conviene un disparador inmediato.
Un solo resumen, no una lluvia de alertas
Otro punto clave es la cadencia de los mensajes. Nadie quiere recibir una notificación cada vez que cambia algo.
La propuesta es mandar un solo resumen con lo importante. Un digest, un solo flujo de información, en un canal definido.
Dentro de ese resumen, defines qué es importante, qué es crítico y qué requiere escalar. Así el equipo sabe dónde poner la atención primero.
El horario también es parte del diseño
Esti y Fran se rieron con este punto, pero es muy real. No tiene sentido mandar el mensaje a la noche, porque nadie lo va a leer y todos se van a molestar.
Peor aún, la gente termina silenciando el canal. Y un canal silenciado es un agente que trabaja para nadie.
Por eso necesitas elegir una hora en la que los usuarios estén activos. En la demo eligieron las 7 de la mañana, el momento del primer café.
Casos de uso más allá del monitoreo técnico
El escenario de la demo está muy ligado a la salud de la organización. Pero Fran pidió pensar en casos propios, y mostró algunos ejemplos.
En servicio, puedes detectar un caso que no tiene actividad. En ventas, puedes detectar una oportunidad grande que no tiene actividad y avisar antes de que se enfríe.
Para equipos comerciales que venden por mensajería, esta lógica conecta muy bien con herramientas como Sellium. Y si tu foco está en campañas, también puedes aplicarla con Revio.
Hubo un ejemplo más curioso. Los hermanos implementaron una serie de funcionalidades que dependen de que ciertos campos estén completos, y crearon un agente que entiende si esas funcionalidades se están usando o no en la organización.
Ese tipo de señal sirve para medir adopción. Si además quieres convertir esos datos en respuestas rápidas para la dirección, un enfoque de BI conversacional como Metrix va en la misma línea.
La idea de fondo se repitió varias veces: nadie conoce tu organización mejor que tú. Piensa en tus propias señales y tus propios casos, y aplica la técnica ahí.
Cómo empezar en tu propia organización
Al cierre, Fran dejó una lista de recomendaciones concretas. Son simples, pero ordenan el camino.
Aprende los fundamentos en lugar de copiar una automatización tal cual.
Mapea tus señales: define qué es una señal para tu negocio y qué no.
Aprende a construir agentes, que son la base para tomar decisiones con IA.
Empieza con un solo escenario, automatízalo y suma más solo si ves que agrega valor.
Prepárate para ajustar, porque el sistema no queda perfecto de entrada.
Fran se disculpó por ser repetitivo con el mapeo de señales. Pero tiene razón en insistir: ese es el paso que define si el agente te ayuda o te llena de ruido.
También contó que grabaron una serie de videos con toda la demo paso a paso. Ahí muestran cómo conectar Slack con Salesforce, cómo crear el Flow y cómo armar el agente y sus acciones, que en la charla tuvieron que saltear por tiempo.
Si quieres seguir aprendiendo sobre agentes y Salesforce, en Pulse publicamos artículos como este de forma regular. Y en recursos encuentras material descargable para tu equipo.
Por qué este enfoque sirve a empresas medianas
Lo más valioso de la técnica es que combina tres herramientas que probablemente ya tienes. Flow, Agentforce y Slack no son productos nuevos para la mayoría de los equipos de Salesforce.
Para empresas medianas, eso significa empezar sin un proyecto gigante. Un Schedule Flow, un agente con buenas reglas y un canal de Slack alcanzan para el primer caso.
Si quieres saber qué cuesta llevar agentes a tu operación, revisa nuestros precios. Y si prefieres conocer primero al equipo detrás de Vantegrate, pasa por quiénes somos.
Tu primer agente proactivo, mañana a las 7
El cambio que propusieron Fran y Esti es de mentalidad. Dejas de preguntarle a la IA y empiezas a recibir lo que importa, priorizado, en el lugar donde ya trabajas.
Elige una señal, define el horario y deja que el agente haga el análisis por ti. Si quieres ayuda para diseñar ese primer escenario, agenda una demo y lo armamos juntos.
