La Data Table de los Screen Flows ahora acepta colecciones definidas en Apex como Source Collection. Eso significa que lo que arma tu clase de Apex puede ir directo a la tabla, sin crear un objeto custom ni registros temporales solo para mostrarlo. Soy Juan Manuel Garrido, fundador de EGA Futura y cofundador de Vantegrate, y en más de 30 años haciendo software para empresas aprendí a valorar estas mejoras chicas que sacan fricción real.
Lo conté hace unas horas en LinkedIn con un cómic: Apex tiene los datos, nosotros estamos creando un objeto para mostrarlos, y la Data Table pide que se los pasen directo. Acá lo desarrollo con más detalle: qué cambió, cómo se configura, qué todavía no hace y dónde lo usaría en un proyecto real sobre Salesforce.
Qué problema resuelve esta mejora de la Data Table?
Nos acostumbramos tanto a los parches que empezamos a llamarlos arquitectura. Si alguna vez tuviste que mostrar en un Screen Flow lo que devolvía una acción de Apex, seguramente pasaste por alguno de estos caminos: crear un objeto custom espejo de tu clase, insertar registros temporales para después borrarlos, meter un elemento Transform para convertir la colección en algo que la Data Table aceptara, o directamente construir un Lightning Web Component propio.
Todos funcionan, pero todos agregan piezas que alguien tiene que mantener. Y en una Org que ya tiene años de historia, cada objeto de más y cada automatización de más se suman a la deuda técnica, como conté en cómo ordenar Workflow Rules, Process Builder y Flow sobre el mismo objeto.
Qué cambió exactamente en Winter ’26?
Desde Winter ’26, con la API 65.0 o superior, el componente Data Table de los Screen Flows acepta como Source Collection no solo colecciones de registros, sino también colecciones de tipos de datos definidos en Apex. Traducido: la colección que arma tu Apex va directo a la tabla.
- Sin objeto intermedio.
- Sin registros temporales.
- Sin Transform solo para cambiar el tipo de la colección.
Cómo se configura el Unique Identifier?
La clave es una opción nueva en la configuración del componente: el Unique Identifier. Como una clase de Apex no tiene un Id de registro, la Data Table necesita saber qué campo identifica cada fila. El flujo de trabajo queda así:
- Escribe una acción invocable en Apex que devuelva una colección de tu clase, con sus campos marcados para que Flow los pueda leer.
- En el Screen Flow, llama a esa acción y guarda el resultado en una variable de colección del tipo definido en Apex.
- Agrega la Data Table a la pantalla y elige esa variable como Source Collection.
- En Unique Identifier, elige el campo que identifica cada fila: un recordId, una ciudad, un código de moneda, lo que sea único en tu caso.
- Configura las columnas y el modo de selección como harías con registros normales.
A partir de ahí, la Data Table trata cada elemento de la colección como un registro. El usuario puede seleccionar filas y esas filas quedan disponibles para usarlas más adelante en el Flow, por ejemplo para pasarlas a otra acción de Apex o para decidir el siguiente paso.
Qué todavía no se puede hacer?
Para no vender humo: por ahora es mostrar y seleccionar. La edición inline de celdas con colecciones de Apex todavía no está disponible y sigue pendiente para una próxima release. Si tu caso necesita que el usuario corrija valores dentro de la tabla, por ahora vas a seguir necesitando otra pantalla, inputs aparte o un componente propio.
No es la feature más vistosa del release, pero es de esas que se notan en el día a día de quien arma Flows.
Dónde usaría esto en un proyecto real?
- Datos de una API externa: cotizaciones de monedas o acciones que traes con un callout y quieres mostrar sin guardarlas.
- Cálculos financieros resueltos en Apex: simulaciones, cuotas o escenarios que el usuario compara y elige.
- Resultados de un proceso batch que no tiene sentido persistir en Salesforce.
- Pantallas internas armadas en minutos, sin sumar objetos a tu Org.
Si te interesa el lado de las integraciones con Flow, en la Masterclass sobre integraciones sin código con Flow mostramos cómo traer datos externos sin escribir Apex. Y si quieres sacarle el jugo a cada release, te recomiendo esta Masterclass de hacks y trucos para los releases.
Qué gana tu empresa con menos lógica de transformación?
Lo que te destraba en concreto es menos lógica de transformación en el Flow, datos externos en pantalla sin crear objetos custom, el mismo comportamiento para datos nativos y datos de Apex, y prototipos mucho más rápidos. Para una empresa mediana eso se traduce en menos piezas que mantener y menos riesgo cuando cambia el equipo que administra la Org.
Es la misma filosofía con la que construimos EGA Futura, el ERP nativo para Salesforce: aprovechar lo que la plataforma ya resuelve en lugar de agregar capas por fuera. Y cuando el proceso pide automatizar sin código, nuestro motor de automatización de procesos trabaja sobre los mismos datos. Si recién empiezas con Flow, en EGA Futura damos clases de Salesforce en vivo y gratis todas las semanas.
Te dejo la misma pregunta que hice en la conversación de LinkedIn: qué armarías con esto?
Preguntas frecuentes
Se puede usar una colección de Apex como Source Collection de una Data Table en Screen Flow?
Sí. Desde Winter ’26 (API 65.0 o superior), el componente Data Table de los Screen Flows acepta colecciones de tipos de datos definidos en Apex como Source Collection, además de colecciones de registros.
Para qué sirve el Unique Identifier de la Data Table?
Le indica a la tabla qué campo de tu clase Apex identifica cada fila, por ejemplo un recordId o un código. Con ese campo la Data Table trata cada elemento de la colección como si fuera un registro y permite seleccionarlo. Conviene que el valor no se repita entre filas.
Se pueden editar inline las filas que vienen de Apex?
Por ahora no. Con colecciones definidas en Apex la Data Table permite mostrar y seleccionar filas, pero la edición inline de celdas sigue pendiente para una próxima release.
Sigo necesitando un objeto custom o un elemento Transform para mostrar datos de Apex?
Para mostrarlos y seleccionarlos en pantalla, ya no. La colección que devuelve tu acción de Apex puede ir directo a la Data Table, sin objeto intermedio ni registros temporales.
Qué casos de uso tiene esta mejora?
Datos traídos de una API externa, como cotizaciones de monedas o acciones, cálculos financieros resueltos en Apex, resultados de un proceso batch que no quieres persistir y pantallas internas que necesitas armar rápido sin sumar objetos a tu Org.
Recibe estas ideas en tu correo
Si te sirvió esta guía sobre Flow y Apex, suscríbete gratis al newsletter de EGA Futura en Substack y recibe cada artículo nuevo directo en tu correo.