Hace poco, Vantegrate grabó otra masterclass de los jueves a los palos: hacks y trucos para sacarle el jugo a lo mejor de los últimos releases.
El ángulo no es un brochure de features ni un replay de Spring '26. Es un mapa de píldoras que cambian el día a día en Flow, Apex, LWC, Agentforce y aprobaciones.
La clase completa está en YouTube. Juan Manuel Garrido (JuanMa) condujo con Francisco Morales (Fran) y Josué Mendoza (Josu).
En la bienvenida también nombraron a Angie Cagliolo. El foco técnico lo llevaron Fran y Josu con JuanMa en la conducción.
Fran lo dijo sin vueltas. Van a mostrar lo interesante de Summer '26 y, al final, algunas cositas que no necesariamente nacieron en ese release, pero que hoy conviene tener en el radar.
El equipo de Vantegrate armó la clase para que se lleven el concepto aunque alguna org todavía no tenga la licencia o el flag listo. Si viven en el CRM de Salesforce, esta es la masterclass de oficio: atajos reales, no solo release notes.
Pulse (y Vanguard al pasar): dónde queda el contenido
A partir de esta masterclass, el equipo anunció Pulse: el blog en vantegrate.com/pulse.
Ahí van a publicar artículos, novedades y el material de las masterclasses. El eje gira alrededor de inteligencia artificial, con opinión de mercado y detalles técnicos cuando hace falta más profundidad que un posteo suelto.
Fran también mencionó Vanguard (el portal de estudio) al pasar: módulos para aprender Salesforce y apuntar a certificaciones, con novedades en camino (entre ellas Agentforce y Data Cloud).
En Pulse ya pueden resumir artículos con distintos motores de IA, bajar PDFs de presentaciones y seguir el ciclo sin perder el hilo. En recursos y en Pulse queda el rastro de lo que vieron en vivo.
JuanMa empujó a la comunidad a meterse: entrar, usar los botones de resumen y participar. La idea no es futurología; es tener un lugar friendly donde el contenido de las clases no se evapore.
Agentforce dentro de Flow: crear el agente como si fuera un subflow
La novedad fuerte de Summer '26 (con matices de licencia) es poder crear un agente desde el Flow Builder, no solo invocar uno existente.
Antes ya podían llamar un agente con un prompt de arranque y capturar (o ignorar) la respuesta. Ahora la creación queda embebida en el canvas: definen instrucciones y acciones sin salir a Agentforce por otro lado.
Fran lo ancló con una analogía clara. Piénsenlo como un subflow, pero el artefacto que crean es un agente reutilizable.
Caso de uso que plantearon: un trigger Flow sobre Opportunity. Al cambiar de etapa, crean (o reusan) un agente que lee mails y comentarios, arma un summary y lo pega en un campo.
La magia operativa está en el nodo: el prompt con el que "despiertan" al agente, la forma esperada de la respuesta y qué hacen después con ese output dentro del Flow.
Cuidado con las re-preguntas en contexto headless
Acá viene el warning que Fran había dejado en la masterclass de Slack. Si el agente corre headless (disparado por un Flow, sin humano chateando), una re-pregunta lo deja colgado.
Den instrucciones concretas: están dentro de un Flow; no hagan re-preguntas; con la información disponible actúen; si hay duda, mejor no hagan nada.
Si el summary va a un campo de 255 caracteres, díganlo también. Si no, el agente puede devolver texto que rompe el update.
Para equipos que diseñan agentes de IA sobre Salesforce, el takeaway es de arquitectura: crear el agente en el Flow no borra la necesidad de gobernar el prompt y el contrato de respuesta.
Apex: strings multilínea con triple comilla (y JSON sin drama)
El hack más terrenal de la clase: en Apex ya pueden armar strings de muchas líneas con triple comilla.
Antes era el clásico infierno de comillas, + y saltos de línea. Ahora tiran el bloque de texto adentro y queda legible.
El caso que más muestran en release notes es JSON: abren la triple comilla, arman el payload y listo. También ayuda cuando arman queries dinámicas con muchos criterios.
Fran mencionó de pasada (no es nuevo del release, pero suma) la clase JSON Generator: abren objeto, setean campo, abren lista, sin concatenar strings a mano.
Juan Diego Navarro, desde el chat, sumó el uso en test classes: simular inputs JSON larguísimos sin volverse loco. Para developers de Salesforce, es higiene diaria.
LWC state management: una capa compartida (como React)
Fran bajó un concepto más difícil de demoar en vivo: state management en Lightning Web Components.
La idea, a groso modo, es una capa de estado compartida. Varios componentes consumen esa capa en lugar de pegarle cada uno al backend por la misma Opportunity.
Analogía que Salesforce pone en la documentación (y que el chat confirmó): igual que en React.
Antes: muchos componentes, muchas queries, eventos para sincronizar. Ahora: un state manager centraliza datos; line items y resumen miran la misma fuente y quedan actualizados juntos.
No tiene sentido si el LWC es standalone a pantalla completa. Sí tiene sentido cuando hay varios componentes interactuando en la misma experiencia.
Fran también conectó esto con la apuesta headless de la plataforma: fabricantes que meten un componente rico sin casarse del todo con el modelo de datos interno, y después orquestan por detrás.
Si están midiendo rendimiento y coherencia de UI, esto baja a seguridad de datos y a diseño de capas, no solo a "bonito en Lightning".
Fechas relativas en Flow: is today, esta semana, este mes
Otra píldora rápida: en Decision de Flow pueden comparar fechas con evaluadores relativos.
Ejemplos que trajeron: si la fecha es hoy, si está en esta semana, este mes, este año, o en el último mes/semana/año (e incluso aniversario / cumpleaños).
Antes había que restar días y pelearse con meses de 28, 30 o 31. Ahora el operador debería aparecer cuando eligen un campo fecha en la lógica del decision.
En el jueves de la masterclass no lo encontraron estable en todas las orgs (posible beta). El mensaje fue el de siempre: llévense el concepto; cuando esté listo en su org, el ahorro es real.
Caso chico: recordatorio si una fecha cae dentro del mes corriente, sin fórmulas artesanales.
Preview local de LWC: sin Lightning Page ni Ctrl+Shift+R
Josu no pudo sumarse a la demo en vivo, pero el equipo lo dejó cortito y al pie: preview local de Lightning Web Components en VS Code (o incluso en el browser).
Ya no necesitan meter el componente en una Lightning Page de mentira solo para ver cómo se ve. Tampoco el ritual de Ctrl+Shift+R y cache.
Codifican y ven el cambio en vivo. Menos anécdotas de componentes de prueba que se van a producción en una página que no tenía nada que ver.
Para admins que entregan UI y para developers que iteran, es velocidad pura. Si quieren verlo aplicado en una demo de producto, el patrón es el mismo: feedback visual sin fricción de org.
LWC en Dashboards: un widget, meta tag y permisos
Esta fue "la bomba" del bloque UI. Pueden meter un LWC como widget dentro de un Dashboard estándar.
Límite importante: hasta uno. Salesforce empuja a no reemplazar todo el dashboard con componentes custom.
El patrón que defendieron: usen reportes y dashboards estándar siempre que puedan; cuando se queden cortos, sumen un LWC para lo que el reporting nativo no llega.
Para habilitarlo, el componente necesita el meta tag que lo marca como enabled for dashboard. Después, en el builder del dashboard, agregan el widget y eligen el LWC.
Cuidado con permisos: están salteando parte del modelo de reportes. No es solo "se ve lindo"; es qué datos expone ese componente y a quién.
Josu y Fran dejaron preguntas abiertas que todavía querían probar: si el LWC recibe filtros del dashboard, y qué pasa si adentro del único slot meten varios gráficos embebidos. Concepto claro; edge cases a testear en sandbox.
Quienes arman experiencias operativas (incluso con piezas tipo Arconte) van a reconocer el trade-off: potencia custom sin tirar a la basura el estándar.
Aprobaciones: Slack headless y aprobación unánime
Aprobar desde Slack (sin abrir Salesforce)
Salesforce sigue empujando la narrativa headless. En aprobaciones (clásicas o basadas en Flow) la notificación puede llegar por web, móvil y ahora también por Slack.
No es solo un ping. El mensaje es interactivo: aprueban o rechazan con comentario desde Slack, y el proceso vuelve a Salesforce en tiempo real.
Todo queda en el Approval Trace. Menos fricción, aprobaciones más rápidas, Salesforce sin abrir Salesforce.
Requisito práctico que trabó la demo: tener la org conectada con Slack (Fran mencionó el conector / setup que en sandbox de cliente no quiso forzar). Canal extra, no exclusivo: Salesforce, app móvil y Slack conviven.
Unanimidad en el step (versus first to approve)
Lo nuevo en grupos: pueden exigir aprobación unánime en el step.
Antes, si asignaban a un rol, el primero que aprobaba ganaba (first to approve). Si necesitaban a Fran y a Josu, encadenaban pasos.
Ahora, con unanimidad, todos los asignados del step tienen que aprobar para avanzar. Si uno rechaza, el registro vuelve aunque el resto haya aprobado.
JuanMa dejó una reflexión de compliance: Salesforce siempre fue "cuadrado" con aprobaciones (incluso mass approve es doloroso a propósito). Si están aprobando descuentos o temas con vínculo legal, el diseño rígido protege.
Fran sumó el espejo del proyecto real: el cliente pedía aprobar de a 100 registros. Si aprueban tanto, ¿están revisando algo?
El guardrail de plataforma a veces es el feature. Eso conecta con gobernanza y con cómo miran precios y riesgo operativo: no todo atajo ahorra plata al final.
Apex API 67: SOQL en user mode y with sharing por defecto
Josu bajó la alerta de breaking change. Las clases Apex que suban a API 67 cambian el comportamiento por defecto de las queries.
SOQL en user mode por defecto: se respetan field-level security y permisos de quien ejecuta. Si la clase no declara sharing, queda with sharing por default.
Traducción operativa: queries que antes devolvían datos pueden fallar por sharing o FLS al bumpear la API version. Salesforce lo documenta como ajuste de seguridad de datos, no como bug.
Triggers siguen en system mode. Edge cases aparte, el mensaje fue único: testeen al subir a 67.
También se despiden (en la práctica) de pelear tanto con WITH SECURITY_ENFORCED: el modelo se ordena en user mode versus system mode. Si un LWC o una clase vivía "sin sharing" por costumbre, el upgrade puede romper en silencio hasta el primer test.
Fórmulas en SOQL: comparar campos en el WHERE
Píldora corta pero potente: ahora pueden usar fórmulas dentro del WHERE de SOQL.
Antes no comparaban un campo con otro en la misma query de forma limpia. Traían la lista y filtraban en un for.
Ejemplo de la clase: oportunidades donde Amount * Discount sea mayor a mil, resuelto en la query. Menos filas en memoria; menos custom fields inventados solo para poder filtrar.
En el vivo no lo ejecutaron en la org de demo, pero el concepto quedó: empujen el filtro al motor, no al loop.
Chatter apagado por defecto (y otras cositas del release)
Entre las "cosas locas" que sumaron al final: Chatter viene apagado por defecto (más headless, más Slack).
También mencionaron expansión de dark mode (más superficies de Setup), mejoras alrededor de AIDs para email templates y Flow (deploy menos doloroso) y el panel de validación / warnings de Flow Builder rediseñado.
Sin inventar roadmap: son señales de hacia dónde empuja la plataforma. Si Chatter era ruido en su proceso, el default nuevo alinea con lo que ya venían debatiendo en la comunidad.
Comunidad: WhatsApp, QR, voucher y códigos Vanguard
Antes de cerrar, JuanMa compartió el QR del grupo privado de WhatsApp. Ahí circula material que no publican en otro lado, se responden consultas técnicas y se ayuda entre todos.
Meta impone un techo de integrantes: escanear ahora asegura lugar. También recordaron el sorteo del voucher de certificación (códigos que coleccionan en las clases) y la dinámica nueva con Pulse.
Los primeros que compartan screenshot de un resumen IA en el grupo reciben código de acceso a Vanguard. No es hard-sell: es comunidad más estudio.
Si quieren seguir el ciclo de masterclass, Pulse y el grupo son la puerta. El marco de cómo trabajan cierra en transparencia de datos.
El jueves de la masterclass dejaron muchas píldoras sueltas a propósito. Summer '26 no se come de un saque: se prioriza, se prueba en sandbox y se lleva el concepto aunque el flag todavía no esté verde en su org.
