El 5 de marzo, Vantegrate grabó una masterclass de los jueves a los palos. El foco fue Spring '26 y lo que realmente cambia cómo trabajan admins y developers.
La clase completa está en YouTube. Juan Manuel Garrido (JuanMa) la condujo con Esteban Morales (Esti, Bebé Corazón), Francisco Morales (Fran) y Josué Mendoza (Josu) encima del Release.
El equipo de Vantegrate lo dejó claro de entrada. Hoy no es un deck eterno de release notes: es práctica que pueden aplicar al toque (con una excepción que todavía falla).
Fran prometió full demo. Esti trajo el mapa: Winter '26, mejoras viejas que muchos no usan, y lo nuevo de Spring '26.
Josu cerró con el golpe de seguridad en Connected Apps. Si viven de integraciones, ese bloque solo ya justifica el recording.
Por qué mirar el Release (y no solo el hype)
Salesforce sigue bautizando versiones con estaciones. JuanMa lo ironizó al pasar: clientes en dos hemisferios, mismo nombre climático.
Más allá del chiste, el Release es el ritmo oficial. Tres veces al año (aprox.) llega lo que Trailhead, Help y las orgs van a empujar.
El truco de la clase no fue memorizar el PDF. Fue priorizar: qué miran primero admins de Flow, qué miran developers de Apex, qué no pueden ignorar en integraciones.
También mezclaron releases. No todo lo útil nació en Spring '26; hay piezas de Winter '26 (y anteriores) que en orgs reales siguen siendo noticia porque nadie las activó.
Si viven en el CRM de Salesforce, este mapa les ahorra horas de releer release notes sueltas. En Pulse y recursos encuentran el ciclo de estas masterclass.
La promesa operativa es simple. Salen de la clase y ya pueden probar casi todo en sandbox (menos el pedazo de Agentforce que todavía pelea).
1. Analíticas de Flow: ver fallos y caminos (no solo el mail)
Esti abrió con analíticas de Flow. Reportes y vistas para ver ejecuciones, fallidos y rutas tomadas.
Una entrevista es una ejecución del Flow. El Flow es el contenedor; cada corrida es una entrevista.
En Pause and Fail Flows ven fallos, versión, tipo y mensaje. Dejan de depender solo del mail plano que llega a la casilla del admin.
Fran lo comparó con herramientas tipo Make o Zapier. Salesforce metió observabilidad visual donde antes había texto críptico.
El caso de uso es brutal. Flows que parecen el mapa del subte: necesitan saber qué camino se toma y dónde duele.
Esti armó un Flow corto (Opportunity a Qualification, decisión por Type). En total runs vio si corrió, y si entró al branch de New Customer.
JuanMa sumó el dolor clásico. Cada fallo manda un correo; esto te cambia el foco a algo visual y accionable.
Hay otra capa más fina (Flow logs / Open Items) que en la demo venía atada a Data Cloud. Fran y Esti separaron bien dos mundos.
Una cosa es el analytic básico habilitado para todos. Otra es el logging profundo por ejecución (valores, caminos detallados) cuando tienen esa pieza activa.
Si solo necesitan fallidos y corridas, ya tienen material. Si quieren el detalle tipo "qué valor tenía cada variable", revisen el logging avanzado.
2. Flow Tests: calidad antes de romper producción
El segundo bloque fue Flow Tests. Idea hermana del Apex testing, llevada al mundo declarative.
Crean un test con un registro existente, definen el evento (cambio de Stage, por ejemplo) y arman assertions sobre el resultado esperado.
Limitación clara (la dijeron sin maquillaje). No es como Apex Test: no crean data adentro del test; el registro ya tiene que vivir en la org.
JuanMa preguntó si es "un debug con otro nombre". Fran matizó con precisión de oficio.
El debug investiga qué pasó. El test asegura calidad cada vez que tocan algo y no quieren romper lo anterior.
También pueden transformar un debug en test. Útil cuando heredan un Flow gigante y quieren documentar "con este registro, debería terminar así".
Fran admitió un atajo de developer. En Record-Triggered a veces iría directo a Apex test desde Cursor o Antigravity.
La utilidad posta la ve más donde el debug de pantalla se vuelve engorroso. Esti lo dejó como herramienta a usar más, no como religión TDD.
No es magia masiva. Es red de seguridad para no romper lo que ya andaba en producción.
3. Flow Trigger Explorer: orden, filtros y cordura
Después vino el Flow Trigger Explorer. Para orgs complejas, JuanMa lo comparó con una app de AppExchange que pagarían sin dudar.
Ven automatizaciones por objeto y por trigger. Arrastran el orden de ejecución con un gesto.
Fran lo clavó en una frase. Muchos "en sandbox anda y en prod no" eran orden mal puesto.
En este ciclo mejoraron filtros. Activos, orquestadores, managed packages, estándar: menos ruido, más foco.
También mostraron el launcher más friendly de Flows (versiones, descripción, sharing a nivel admin). Ojo con el matiz de permisos.
El sharing que vieron aplica distinto en trigger vs Screen Flow. Para pantallas, quién ejecuta sigue otro camino.
El Explorer brilla en el mundo record-triggered. Si su org tiene capas apiladas, este es el mapa antes de tocar un solo nodo.
4. Screen Flows reactivas: sin alambre ni botón inventado
Esti pasó a pantallas reactivas. Fórmulas y componentes que se enteran cuando cambia un valor en la misma pantalla.
Ejemplo clásico. Nombre + apellido alimentan una fórmula de nombre completo; ahora el motor reacciona y pueden actualizar UI en vivo.
Antes había que forzar "Siguiente", validar, volver, o inventar un LWC con booleans. Fran lo leyó como salto arquitectónico.
Pasaron de un MVC rígido a un modelo más de eventos. Todo se entera de lo que pasa en la pantalla.
Para developers: un LWC embebido puede avisar al Flow que un valor cambió (atributo de refresh). Así desacoplan componentes y dejan la orquestación en el Flow.
JuanMa recordó el hack viejo. Escondían el Next nativo y fabricaban un botón custom en Lightning Web Component.
Hoy, mucha de esa gimnasia sobra. Si construyen pantallas de captura, esta feature sola ya justifica revisar Screen Flows viejos.
5. Data Tables editables: el Excel que pedía el negocio
Acá sí, Esti marcó full nuevo de este Release: Data Tables editables en Screen Flow.
Antes la tabla era casi solo lectura. Ahora marcan columnas con Edit column values, el usuario edita, y ustedes toman el output.
Fran aclaró el matiz clave. Dibujar la tabla editable no guarda solo: ustedes deciden qué hacer con el output (actualizar, colecciones, loops).
Caso de uso inmediato. Cabecera de pedido con muchas líneas: un botón, una pantalla, editar montos o nombres sin entrar registro por registro.
Pueden sacar solo las filas editadas, la selección, o la primera seleccionada. Menos bulk ciego, más intención del usuario.
JuanMa miró el patrón histórico. Cada vez que Salesforce saca un feature, el negocio pide edit inline.
Pasó con reportes, con related lists, ahora con data tables. Es la eterna pelea contra exportar a Excel.
Bonus de UX en la misma demo. El debug de Screen Flow ya no los saca a otra pestaña.
Ven pantalla y panel juntos. Pequeño detalle, pero cambia la velocidad de prueba.
6. Agentforce en Flow: la promesa (y lo que todavía falla)
Fran bajó a tierra la promesa de Agentforce editando Flows. Botón en el builder, chat, cambios propuestos, ustedes aprueban o rechazan.
En Dreamforce lo mostraban imponente. En la masterclass, la mala noticia: no lo pudieron hacer andar de forma confiable.
Hasta artículos de Salesforce admitían límites. La creación inicial a veces responde; el dolor aparece al pedir cambios iterativos.
Error interno. "Necesito más detalle", aunque el prompt sea quirúrgico.
Esti lo probó en vivo. Con instrucciones muy específicas (hasta "agregá una Decision") llegó más lejos.
Fran había renegado horas sin suerte. La config de org importa más de lo que el brochure cuenta.
JuanMa contó soporte real de la semana previa (Data Cloud + Agentforce): caso, acceso remoto, dejaron andando. Eso no magia el editor de Flow todavía.
Si exploran agentes en el stack Vantegrate, el mapa está en agentes de IA. Acá el mensaje fue honesto.
Feature anunciada.
Gobernanza de expectativas. Y volver a probar en releases siguientes.
Para arquitectura de copilots y demos, también pueden mirar una demo cuando toque conversación de producto. No confundan brochure con lo que vieron en pantalla.
7. Apex Cursors: volumen grande sin romper la org
Esti cerró el bloque técnico con Apex Cursors (Spring '26). Lo comparó con el salto histórico de Batch Apex.
Idea central. Pueden apuntar a volúmenes enormes (habló del orden de 50 millones de registros como techo de conversación) y trabajarlos sin el patrón rígido de siempre.
No reemplaza Batch de un día para el otro. Se combina con Queueable (encolables) para procesar en asíncrono con límites más flexibles (CPU, heap).
Repaso rápido que dio Esti. Batch: start + execute + finish, pensado para lotes.
Queueable: más flexible, asíncrono. Cursor: les dice qué traer y habilita recorrer ese set a escala.
Mostró código, pero avisó que merece otra clase. Para developers de Salesforce, el takeaway es claro.
Hay una herramienta nueva en el cinturón cuando el volumen asusta. Si su org ya pelea con jobs eternos, cursors + queueable es el experimento de sandbox de la semana.
No inventen magia. Midan governor limits como siempre.
8. Connected Apps y Client Credentials: seguridad que no espera
Josu metió el cambio que duele en integraciones. Spring '26 empuja el modelo sistema a sistema.
Antes: Connected App + client id/secret más usuario, password y token. Eso Salesforce lo está dando de baja para lo nuevo.
Ahora: Client Credentials. Generan credenciales para el sistema externo (SAP, middleware, lo que sea).
Adentro asignan un usuario de integraciones. Así el audit trail sigue teniendo dueño sin que el externo guarde passwords de Salesforce.
Las Connected Apps viejas no caen de un día para el otro. El mensaje operativo fue claro: revisen y migren antes de que el futuro las deje inseguras o bloqueadas.
También mencionaron SAML viejo (versión que ya se considera insegura) y el fin de conectarse por instance URL tipo NA20. Usen My Domain.
Esto conecta directo con seguridad y transparencia de datos. No es feature "linda": es higiene de org.
Si el sistema externo guardaba passwords de Salesforce, este Release les da el empujón para sacarlo. Client id/secret del sistema, usuario de integración adentro, fin del atajo peligroso.
Cómo leer Release Notes sin volverse loco
La clase dejó un método implícito. Primero, separen admin Flow, developer Apex e integraciones.
Segundo, no descarten features de Winter '26 (u otros) solo porque el branding diga Spring '26. Lo que no usaron sigue siendo nuevo para ustedes.
Tercero, prueben en sandbox con data chica. Analíticas, tests, data tables editables y el debug inline se sienten en minutos.
Cuarto, traten Agentforce-en-Flow con curiosidad y escepticismo sano. Documenten qué anda en su org; no asuman el video de keynote.
Quinto, pongan Connected Apps en el backlog de seguridad ya. Es el cambio que les pega de noche si un partner externo autenticaba mal.
Fran avisó que quedó mucha carne para la parte dos. Esta fue la tanda Flow-first con un cierre de código y gobernanza.
En el medio anunciaron (sin spoilear de más) una plataforma de estudio orientada a certificaciones: teoría, práctica y mocks. Accesos pensados para la comunidad de las masterclass.
Sobre precios de producto Vantegrate y arquitectura, la clase no fue brochure. Fue oficio: qué activar, qué migrar, qué esperar.
Si quieren ver cómo Vantegrate piensa agentes, copilots y capa de producto alrededor de Salesforce, el mapa de gobernanza + automatización arranca bien en Arconte.
Para llevarse después del 5 de marzo
Quedaron ocho palancas concretas. Analíticas y tests para no volar a ciegas.
Trigger Explorer para ordenar el caos. Pantallas reactivas y data tables editables para UX sin LWC obligatorio.
Agentforce-en-Flow como apuesta a seguir testeando. Apex Cursors para volumen real.
Connected Apps con Client Credentials para dormir un poco más tranquilos. Suscríbanse al recording en YouTube si se perdieron el vivo.
La parte dos viene con lo que no entró en marzo. Y si su org todavía vive de mails de error y tablas de solo lectura, este Release (más lo que arrastraban de Winter '26) les da excusa perfecta para modernizar sin drama de proyecto eterno.
Prueben una feature por sprint interno. Empiecen por lo visual (analíticas y data tables) y cierren por lo que no perdona: seguridad de integraciones.
