Salesforce Spring ’26 no es un PDF eterno de release notes: es un conjunto de cambios que, si tu empresa vive de Flows, Apex e integraciones, ya se sienten en el trabajo diario.
En esta masterclass de Discover, Juan Manuel Garrido, Esteban Morales, Francisco Morales y Josué Mendoza recorren ocho features con demos en vivo: analíticas de Flow, Flow Tests, Trigger Explorer, Screen Flows reactivas, Data Tables editables, Agentforce en Flow, Apex Cursors y Connected Apps con Client Credentials.
Abajo está el video completo. Después, el mapa editorial para admins y developers: qué activar primero en sandbox, qué sigue inestable y qué no puedes postergar en seguridad. Al final, preguntas frecuentes y la transcripción completa.
Por qué mirar Spring ’26 (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 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 tu empresa trabaja en el ecosistema Salesforce, este mapa te ahorra horas de releer notas sueltas. La promesa operativa es simple: sales de la clase y ya puedes probar casi todo en sandbox (menos el pedazo de Agentforce que todavía pelea).
Esta sesión encaja con otras masterclass recientes de Discover: Data Cloud desde cero, Seguridad y Gobernanza, Experience Cloud en acción y Facturas y Pedidos con Visualforce e IA.
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 ves fallos, versión, tipo y mensaje. Dejas 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: necesitas 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 tienes esa pieza activa.
Si solo necesitas fallidos y corridas, ya tienes material. Si quieres el detalle tipo «qué valor tenía cada variable», revisa 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.
Creas un test con un registro existente, defines el evento (cambio de Stage, por ejemplo) y armas assertions sobre el resultado esperado.
Limitación clara (la dijeron sin maquillaje). No es como Apex Test: no creas 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 tocas algo y no quieres romper lo anterior.
También puedes transformar un debug en test. Útil cuando heredas un Flow gigante y quieres 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ías sin dudar.
Ves automatizaciones por objeto y por trigger. Arrastras 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 tu 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 puedes 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 construyes 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 marcas 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.
Puedes 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 te saca a otra pestaña.
Ves 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 «agrega 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.
Feature anunciada. Gobernanza de expectativas. Y volver a probar en releases siguientes.
Si tu equipo experimenta con agentes, prueba en sandbox y documenta qué responde tu org. No bases un proyecto crítico solo en el video de keynote.
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. Puedes 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: te dice qué traer y habilita recorrer ese set a escala.
Mostró código, pero avisó que merece otra clase. Para developers, el takeaway es claro.
Hay una herramienta nueva en el cinturón cuando el volumen asusta. Si tu org ya pelea con jobs eternos, cursors + queueable es el experimento de sandbox de la semana.
No inventes magia. Mide 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. Generas credenciales para el sistema externo (SAP, middleware, lo que sea).
Adentro asignas 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: revisa y migra 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. Usa My Domain.
Si el sistema externo guardaba passwords de Salesforce, este Release te 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 volverte loco?
La clase dejó un método implícito. Primero, separa admin Flow, developer Apex e integraciones.
Segundo, no descartes features de Winter ’26 (u otros) solo porque el branding diga Spring ’26. Lo que no usaste sigue siendo nuevo para tu equipo.
Tercero, empieza en sandbox con data chica. Analíticas, tests, data tables editables y el debug inline se sienten en minutos.
Cuarto, trata Agentforce-en-Flow con curiosidad y escepticismo sano. Documenta qué anda en tu org; no asumas el video de keynote.
Quinto, pon Connected Apps en el backlog de seguridad ya. Es el cambio que te 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.
Cómo encaja esto con EGA Futura y el AppExchange?
Nosotros construimos un ERP nativo sobre Salesforce. Cuando tu empresa automatiza pedidos, stock o facturación con Flows y Apex, el Release no es teoría: es el suelo donde corre el producto.
Ese producto vive en la nube de Salesforce y está publicado en el AppExchange. Puedes empezar por egafutura.com, mirar la nube del ERP, comparar precios, recorrer productos y, cuando quieras verlo en tu contexto, agendar una demo.
También puedes empezar por el hub de Salesforce en EGA Futura.
Agenda una demo si tu equipo ya pierde horas peleando Flows a ciegas o integraciones con passwords viejos. Empieza por la feature que más duele (analíticas, data tables o Client Credentials) y mide el impacto en una semana.
Qué nos llevamos de esta masterclass?
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.
Prueba una feature por sprint interno. Empieza por lo visual (analíticas y data tables) y cierra por lo que no perdona: seguridad de integraciones.
Nosotros publicamos la grabación en YouTube y este artículo en Discover para que puedas volver al método sin depender del vivo.
Preguntas frecuentes
Cuáles son las 8 features que cubrieron?
Analíticas de Flow, Flow Tests, Flow Trigger Explorer, Screen Flows reactivas, Data Tables editables, Agentforce en Flow, Apex Cursors y el cambio de Connected Apps a Client Credentials (con SAML/My Domain).
Qué es una entrevista de Flow?
Es una ejecución concreta del Flow. El Flow es el contenedor de lógica; cada corrida de un usuario o trigger es una entrevista (útil para ver fallidos y pausados).
Las Data Tables editables guardan solas?
No. Habilitan edición en pantalla y entregan output; ustedes deciden actualizar registros, armar colecciones o iterar solo las filas editadas.
Agentforce ya edita Flows de forma confiable?
En la clase, la UI aparece, pero pedir cambios iterativos fallaba con errores internos en varias orgs. Conviene probar en sandbox y no basar un proyecto crítico solo en el anuncio.
Qué hacer con Connected Apps viejas?
Revisar integraciones que usen usuario/password/token, migrar a Client Credentials (sistema a sistema), chequear SAML actualizado y usar siempre My Domain en lugar de instance URLs.