El 2 de abril, Vantegrate grabó una masterclass de los jueves a los palos sobre Slack y Salesforce.
El ángulo no fue el brochure de marketing. Fue la conexión real que Trailhead apenas bosqueja: de Salesforce hacia Slack, con Flows y acciones out of the box.
La clase completa está en YouTube. Juan Manuel Garrido (JuanMa) condujo con Francisco Morales (Fran), Josué Mendoza (Josu), Esteban Morales (Esti, Bebé Corazón) e invitada Cecilia Chiercki (Ceci / Sisi), solution architect en Sealed Partners (EE.UU., argentina).
Si vienen de las clases recientes de Pulse sobre Spring '26, el foco acá es otro. No es release notes de Apex ni LWC: es integración operativa entre el CRM y el lugar donde el equipo ya conversa.
El equipo de Vantegrate armó el vivo para admins y developers que necesitan dejar de saltar de pantalla en pantalla. En recursos y en el CRM de Salesforce el mapa de plataforma sigue creciendo; esta clase baja a un caso que pueden replicar.
Por qué Slack no reemplaza a Salesforce
Fran abrió con el clima del momento. Salesforce puso mucho peso en Slack y Slackbot como punto de entrada: preguntás qué pasa con una oportunidad y la respuesta aparece sin abrir la org.
JuanMa frenó la lectura extrema. Una licencia de Salesforce y una de Slack no juegan el mismo partido: el CRM sigue siendo el sistema de registro; lo que cambia es la interfaz donde buscan información.
Slackbot coordina y deriva. No crea registros ni reescribe la org: para eso están los agentes y la automatización en Salesforce.
El mensaje operativo quedó claro. Si la org usa Slack, el mail interno y el “avisame por chat” dejan de ser el default: el canal de la oportunidad o del proyecto concentra contexto, historial y próximos pasos.
Eso no mata Chatter por decreto. Más adelante en la clase lo debatieron sin anuncio oficial de “muerte”.
Sí cambia dónde conviene operar el día a día cuando Slack ya es el sistema nervioso del equipo.
Dos vías de integración (hoy miramos una)
Josu marcó el mapa en dos mundos. Uno: están en Slack y disparan cosas hacia Salesforce.
Otro: están en Salesforce (Flows, triggers, datos del CRM) y disparan acciones hacia Slack.
Hoy el foco fue el segundo. Salesforce → Slack, con acciones OOTB (out of the box) que ya viven en Flow sin que escriban Apex.
Ceci lo dijo sin misterio. Antes de magia de agentes o demos lindas, hay un paso obligatorio: conectar la org de Salesforce con el workspace de Slack.
Hay documentación paso a paso (screenshot y favoritos). No hace falta ser developer: seguir el orden.
Slack puede conectar varias orgs de Salesforce (no es 1:1).
Si además quieren Agentforce desde Slack (llamar un agente armado en Salesforce), hay un segundo setup. Ese segundo paso no reemplaza al primero; sin la conexión base no hay nada.
Sandbox primero (también en Slack)
Salvador preguntó por chat si la conexión solo vive en producción. Ceci trabajó todo el caso en sandbox.
Slack también tiene entorno de development (sandbox). Pueden pedirlo aunque en el trabajo diario usen otra herramienta de mensajería.
La regla de higiene es la de siempre. Prototipen en sandbox, prueben el Flow, midan ruido de canales; después muevan a producción.
Nunca al revés.
Para developers de Salesforce esto es territorio familiar: misma disciplina de deploy, otra superficie (workspace, apps, IDs de conversación).
El caso: servicios profesionales de punta a punta
Ceci trajo un caso de servicios profesionales (consultoría / delivery). Oportunidad cerrada ganada → el negocio pasa de ventas a proyectos.
En casi cualquier stack (Certinia, Kantata, Workday o un objeto Project custom) aparece el concepto de proyecto. El trigger del demo: el proyecto pasa a In Progress (activo, listo para ejecutar).
En ese momento el Flow hace el trabajo que hoy suele ser humano y lento:
Crear un canal de Slack nombrado con fórmula (proyecto + fecha, por ejemplo).
Buscar el archivo de alcance (Statement of Work / SOW) asociado al proyecto.
Resumir el documento con un Prompt Template de Agentforce (flex: pregunta + archivo).
Enviar un mensaje de bienvenida al canal con ese resumen.
Pinear el mensaje para que quien entre después lo vea al toque.
Guardar el Slack Channel ID en el registro del proyecto.
Invitar al project manager (lookup de usuario) al canal.
La promesa no es “nunca lean el contrato”. El disclaimer de Ceci fue explícito: el resumen no reemplaza leer el alcance.
Sí evita que cada persona baje el PDF, lo busque y pierda media hora antes de la primera reunión.
Si operan en B2B SaaS o en delivery de implementaciones, el patrón es el mismo: handoff ventas → delivery con contexto en el canal desde el minuto cero.
Acciones OOTB que ya están en Flow
Cuando en Flow agregan una acción y filtran por Slack, aparece un catálogo. Ceci destacó las que usaron (y las que deberían conocer):
Create Slack Channel
Invitar usuarios al canal
Enviar mensaje
Buscar si ya existe un canal (clave para no duplicar)
Archivar un canal
Todo eso sin Apex en el demo. Ceci confesó que pensó que en algún punto había código: no.
Era 100% acciones preconfiguradas.
Governance (el pro tip que más resonó). Si crean canales en automático, diseñen cómo los sacan.
Archivado a los 90 días del cierre del proyecto (Flow agendado) es un ejemplo. Borrar es posible a nivel admin; archivar suele ser lo sano cuando hubo conversación real.
Si llegan a “80 millones de canales”, el problema no es Slack: es falta de estrategia de limpieza pensada el día uno.
Piensen el ciclo completo antes del primer Create Channel. Alta, uso, archivo: tres momentos, un solo diseño.
El Flow en detalle (rama asíncrona)
El diagrama cabe en una pantalla. Trigger: cambio de status del proyecto a In Progress.
Trabajan en la rama asíncrona (Add Asynchronous Path). Con Slack y Agentforce, la rama de run immediately no es el lugar: Flow se los va a negar o va a fallar.
Crear el canal
Acción Create Slack Channel. Parámetros mínimos: app de Slack, workspace, nombre del canal (fórmula).
El output trae el channel ID que encadenan después.
Subflow de archivos + prompt flex
Ceci reutilizó un subflow que localiza el archivo del proyecto (Salesforce Files). Podría vivir en el Flow principal; lo modularizó porque ya existía.
El Prompt Template es flex: input string (la pregunta) + archivo. Pregunta del demo: resumí esto en 250 palabras.
Output: la respuesta del modelo.
Acá viene la arquitectura de prompts. Podrían hardcodear la pregunta dentro del template.
Ceci no lo hizo: reusa el mismo prompt en varios casos y solo cambia la pregunta.
Eso es reusabilidad de verdad (como un Flow o una clase Apex modular). Si no, en un año tienen 500 prompts casi iguales y un dolor de gobernanza.
Quienes diseñan agentes de IA y pipelines de documentos (miren también Arconte) ya pelean ese mismo patrón: menos proliferación, más contratos de input/output.
Mensaje, pin, update e invite
Send message usa el conversation ID (el channel ID del paso 1) y una fórmula de texto: bienvenida + nombre del proyecto + resumen del prompt.
Pin Message toma el message ID del envío y el mismo canal. Quien entre después ve el alcance arriba.
Update Records guarda el Slack Channel ID en el proyecto (Ceci es “obsesiva” con no depender de un query futuro).
Assignment + Invite: meten el PM en una variable (prefijo var en su framework de nombres) e invitan al canal. Si mañana agregan otro lookup de usuario, no reescriben la acción: ajustan la colección.
Framework de nombres (otro oficio). Variables var, fórmulas for, elementos legibles.
Hoy lo mantienen ustedes; mañana lo abre otra persona de Vantegrate o del cliente y tiene que entenderlo sin arqueología.
Consumo: qué gasta créditos y qué no
Josu y Ceci cerraron una confusión cara. Usar acciones Slack OOTB (o Apex custom hacia Slack) no consume créditos de Agentforce.
Llamar un prompt / Agentforce sí entra en consumption. En el demo el costo aparece porque resumieron el SOW; no porque crearon el canal.
Si la org no tiene Agentforce (o no quieren mirar consumo), saquen el bloque del prompt. El Flow sigue siendo válido: canal + mensaje de bienvenida + invite al PM.
Buenas prácticas de Flow aplican al extremo. Eviten DML en loops; piensen límites; diseñen asíncrono.
Un Flow mal armado no solo rompe Slack: traba otros procesos de la org.
Si están midiendo consumption de Agentforce, aíslen el prompt del resto del Flow. Así pueden apagar el resumen del SOW sin tocar la creación del canal ni el invite al PM.
Sobre precios de producto y capacidad, la clase no fue brochure comercial. Fue claridad de arquitectura: separen automatización Slack de créditos de IA.
Canales Slack vs canales Salesforce
Marcelino (desde Wisconsin) preguntó si pueden ver el canal embebido en la Lightning Record Page. Sí.
Hay dos tipos (y confunde a todo el mundo):
Canales Slack: viven en Slack; pueden relacionarse a registros y tener contexto, pero no los ven “adentro” de Salesforce como chat nativo.
Canales Salesforce (en Slack): se ven y se habla en ambos lados; hay componente OOTB de Slack Channel en la Lightning page y botón Open in Slack para linkear un canal existente o crear uno.
Ceci mostró el link del canal creado al registro y la página con el componente. Escribir en Salesforce se refleja en Slack: misma conversación, dos superficies.
No es gratis en costo operativo. Slack pide administración, certificaciones de admin/dev, otro modelo de apps.
Chatter se prende y anda; Slack pide oficio. En orgs donde compensa, la eficiencia del contexto compartido paga ese costo.
Chatter: miedo, historia y nada oficial
El chat empujó el fantasma: “sin Chatter, ¿qué pasa con Field Service y una década de posts?”
La respuesta del panel fue sobria. No hay anuncio oficial de muerte de Chatter.
Hay miles de clientes con trillones de registros de conversación: migrar eso sería un proyecto de costo brutal.
Ceci ofreció su lectura de producto (opinión, no roadmap): el canal Salesforce en Lightning se siente como “te doy lo mismo y más”. Empuja a operar en Slack; no borra de un plumazo el historial Chatter.
Filosofía para el café, no para un ticket de cambio mañana. Operen con hechos de setup y con el caso de negocio; no con rumores de keynote.
Mientras tanto, el caso de esta masterclass sigue en pie aunque Chatter viva cien años más. El handoff de proyecto a canal Slack no depende de esa pelea de producto.
Diagramen antes de tocar la org
Los takeaways de Ceci antes de la demo merecen póster:
Chequen el catálogo OOTB antes de customizar.
Slack + Agentforce → siempre asíncrono.
Prompt / agente → consumption; acciones Slack → no.
No automaticen porque pueden: diagramen el proceso primero.
El producto se mueve semanalmente: Trailhead, Help, masterclass y comunidad no son opcionales.
Eso conecta con seguridad y con cómo cuidan integraciones y datos. Un canal mal gobernado es ruido; una conexión mal pensada es superficie de riesgo.
Si miran políticas de datos, sumen transparencia de datos.
Demo en vivo: del Draft al ruido del canal
Ceci cambió el proyecto (Lima Full Implementation) de Draft a In Progress y guardó. Sin magia manual: se creó el canal, llegó el welcome con el resumen del SOW, la pinearon e invitaron al PM (ella misma en el demo).
El ruidito de Slack fue la notificación de invite. En ese instante, aunque no hubieran tocado el proyecto, el PM ya sabe que fue asignado y tiene el resumen arriba.
El cielo es el límite del mensaje. Pueden sumar fechas de kickoff, contexto del cliente, highlights de reuniones de la oportunidad.
El siguiente Flow natural: al asignar un recurso al proyecto, invitarlo al canal y darle onboarding (Ceci mencionó un use case con preguntas a Confluence desde Slack).
Vanguard, comunidad y el cierre del 2 de abril
Antes del QR, Fran anunció Vanguard: la plataforma de estudio que vienen armando para certificar (teoría propia, quizzes, ejercicios prácticos, mocks). Salen primero con MuleSoft Developer (donde Trailhead ayuda menos) y después OmniStudio.
La liberación es escalonada. Códigos de acceso en el grupo de WhatsApp de la comunidad (capacidad limitada); los primeros que los usen entran.
También van a sortear accesos en próximas masterclass.
Josu compartió el QR del grupo. JuanMa cerró con el ritual de siempre: gracias a Ceci (invitada de lujo, también de inglés para Salesforce), gracias a quien se conectó en feriado, y seguimos el próximo jueves.
Si se perdieron el vivo, el recording en YouTube es el artefacto. Si lo van a implementar, empiecen por el setup org↔Slack en sandbox, listen el catálogo de acciones, diagramen el handoff de proyecto y recién ahí toquen Agentforce.
La del Spring '26 fue Release y oficio de developers. Esta del 2 de abril es la clase de integración que Trailhead no te cuenta con un caso de delivery completo.
Conecten Salesforce a Slack con intención: menos pestañas, más contexto en el canal correcto.
