El modelo mental: evento, criterio y accion
Una pregunta de Flow casi siempre se puede ordenar con tres preguntas: que evento inicia el proceso, que criterio decide si debe continuar y que accion debe ejecutarse. Si el evento es que un registro se crea, actualiza o elimina, estas cerca de un record-triggered flow. Si el evento es una fecha u horario recurrente, revisa schedule-triggered flow. Si el evento es que un usuario necesita avanzar por pantallas, piensa en screen flow.
Despues mira el tipo de accion. No es lo mismo actualizar el mismo registro que disparo el flow, crear registros relacionados, enviar una notificacion, llamar una accion, esperar varios dias o pedir datos al usuario. El examen suele presentar opciones que todas existen, pero solo una respeta el timing y el mantenimiento correcto. Por eso Flow se estudia mejor como decision de arquitectura declarativa, no como lista de botones.
Regla practica: primero identifica cuando ocurre el proceso; despues decide si la accion toca el mismo registro, registros relacionados, el usuario o una fecha futura.
Tipos de flow que debes reconocer
Screen flow guia a un usuario por pantallas. Es candidato cuando la pregunta dice que alguien debe capturar informacion, confirmar decisiones, seguir un asistente o ejecutar un proceso desde un boton o accion. Si el proceso requiere interaccion humana en varios pasos, screen flow suele ser mas apropiado que automatizacion silenciosa.
Record-triggered flow corre automaticamente cuando un registro cambia. Es uno de los tipos mas importantes para Administrator porque resuelve reglas de negocio sobre datos: actualizar campos, crear tareas, mantener consistencia o disparar acciones cuando una oportunidad, caso, cuenta o contacto cumple criterios. Platform event-triggered flow responde a eventos publicados en la plataforma. Schedule-triggered flow corre en un horario y frecuencia definidos para procesar registros sin depender de un cambio inmediato.
Autolaunched flow sin pantalla se usa como logica reusable que puede ser invocada por otros procesos, botones, Apex o subflows. En preguntas de examen, aparece cuando se quiere encapsular pasos repetibles sin UI. La clave es distinguir si el flow debe ser iniciado por un usuario, un cambio de datos, una agenda o una pieza de automatizacion externa.
Record-triggered flows
Un record-triggered flow se configura sobre un objeto y un momento: cuando el registro se crea, se actualiza, se crea o actualiza, o se elimina. Tambien defines condiciones de entrada. Esta parte importa mucho porque un flow que corre en cada actualizacion sin necesidad puede afectar rendimiento y causar efectos secundarios. Si la pregunta menciona que debe ejecutarse solo cuando un registro empieza a cumplir criterios, busca esa opcion.
En Administrator, los escenarios comunes son crear una tarea cuando una oportunidad cambia a Closed Won, copiar datos de una cuenta a un contacto, actualizar un campo calculado de negocio, notificar a un usuario o crear un registro relacionado. El examen no espera que programes, pero si que entiendas que Flow Builder puede automatizar procesos declarativos con condiciones claras y pruebas antes de activar.
Before-save vs after-save
Before-save, tambien llamado fast field updates, es ideal cuando solo necesitas actualizar campos del mismo registro que disparo el flow antes de guardarlo. Es rapido y evita trabajo innecesario. Si el escenario dice "cuando se crea un contacto sin telefono, copia el telefono de la cuenta relacionada al mismo contacto", before-save puede ser candidato si solo se actualiza el registro disparador.
After-save se usa cuando necesitas hacer algo despues de que el registro ya fue guardado: crear o actualizar registros relacionados, enviar acciones, publicar eventos o ejecutar pasos que dependen del ID del registro. Si la pregunta menciona crear una tarea, crear un contrato, actualizar registros hijos o mandar una notificacion despues de un cambio, after-save suele ser mas apropiado.
La trampa comun es elegir before-save porque "suena mas eficiente" aunque el flow necesita tocar otros registros. La eficiencia importa, pero no debe romper el requerimiento. Primero satisface el tipo de accion; despues optimiza. Para preguntas de seleccion multiple, separa cuidadosamente "actualizar el mismo registro" de "crear o modificar registros relacionados".
Scheduled paths y schedule-triggered flows
Un scheduled path pertenece a un record-triggered flow. El cambio del registro dispara el flow, pero una rama se ejecuta despues o antes de una fecha relacionada. Por ejemplo, crear una tarea cinco dias despues de que una oportunidad se gana, o enviar un recordatorio un mes antes de una fecha de renovacion. El registro cambio primero; la accion se difiere.
Un schedule-triggered flow no depende de que un registro cambie en ese momento. Corre segun una frecuencia y puede buscar registros que cumplan criterios. Es mejor para procesos recurrentes: revisar cuentas vencidas cada noche, actualizar estados diariamente o procesar registros que requieren mantenimiento periodico. Si la pregunta dice nightly, daily, weekly, recurring o at a specific time, piensa en schedule-triggered.
La diferencia para el examen es simple: scheduled path es una consecuencia futura de un cambio de registro; schedule-triggered flow es un trabajo programado que revisa registros por cuenta propia.
Subflows, orden y mantenimiento
Subflows permiten reutilizar logica. Si varios flows necesitan los mismos pasos, como calcular una prioridad, validar una condicion o crear un conjunto de tareas, conviene encapsular esa logica. Esto reduce duplicacion y hace mas facil mantener cambios. En el examen, subflow suele aparecer cuando el escenario habla de reutilizacion, consistencia o evitar construir la misma logica varias veces.
Flow Trigger Explorer ayuda a entender y ordenar record-triggered flows para un objeto. Esto importa cuando existen varias automatizaciones que pueden correr sobre el mismo registro. Aunque muchas preguntas de Administrator no entran en detalle profundo, si debes reconocer que demasiados flows desordenados vuelven dificil diagnosticar errores.
Tambien es importante probar. Flow tiene herramientas de debug, y los cambios deben validarse en sandbox o entorno de prueba cuando afectan datos reales. Una automatizacion mal probada puede actualizar registros incorrectos muy rapido. El buen criterio de examen combina facilidad declarativa con control, pruebas y mantenimiento.
Errores comunes al estudiar Flow
El primer error es pensar que Flow siempre reemplaza cualquier cosa. Flow es potente, pero si la pregunta pide aprobacion formal, tal vez sea approval process. Si pide logica muy compleja, integracion especializada o transacciones avanzadas, Apex puede aparecer. Si pide guiar a un usuario por pantallas, no elijas record-triggered solo porque "automatiza".
El segundo error es ignorar el momento de ejecucion. Muchas respuestas incorrectas fallan porque corren demasiado pronto, demasiado tarde o demasiadas veces. Antes de elegir, subraya palabras como before save, after save, related records, scheduled, recurring, user input y only when updated to meet conditions.
El tercer error es no pensar en mantenimiento. Una respuesta que crea cinco flows duplicados puede funcionar, pero no ser la mejor. Una respuesta que usa subflows, condiciones de entrada claras y un alcance pequeno suele ser mas defendible. Salesforce Administrator premia soluciones declarativas, nativas y faciles de mantener.
Checklist de decision rapida:
- El proceso inicia por usuario, cambio de registro, horario o evento?
- La accion actualiza el mismo registro o registros relacionados?
- Debe ocurrir inmediatamente, en una fecha futura o de forma recurrente?
- Necesita pantallas e input del usuario?
- La solucion evita duplicacion y se puede probar con seguridad?
Preguntas frecuentes
Flow reemplaza a Workflow Rules y Process Builder?
Para estudio de Administrator, piensa en Flow como la herramienta declarativa principal para automatizacion nueva. Workflow Rules y Process Builder son tecnologias heredadas en muchas organizaciones, pero el examen moderno premia reconocer Flow Builder como la opcion flexible y actual para automatizaciones declarativas. Aun asi, una pregunta puede mencionar una org existente con automatizaciones antiguas; en ese caso, lee si pregunta por mantenimiento, migracion o una solucion nueva.
Cuando debo elegir screen flow en vez de record-triggered flow?
Elige screen flow cuando el usuario debe interactuar con pantallas, ingresar datos, confirmar pasos o seguir un asistente. Elige record-triggered flow cuando el proceso debe ejecutarse automaticamente por un cambio en datos. Si la pregunta habla de guiar a un agente de soporte por una captura de informacion, screen flow es candidato. Si habla de actualizar datos cuando se guarda un caso, record-triggered flow es candidato.
Por que no usar siempre after-save?
After-save es necesario para acciones y registros relacionados, pero no siempre es la opcion mas eficiente. Si solo necesitas cambiar campos del mismo registro antes de guardar, before-save suele ser mejor. En preguntas de examen, no elijas after-save por costumbre: confirma si el flow necesita el ID del registro, tocar registros relacionados o ejecutar acciones posteriores.
Recursos oficiales y practica
Para estudiar Flow, combina teoria con escenarios pequenos. Crea un flow que actualice el mismo registro, otro que cree una tarea relacionada y otro que use scheduled path. Despues practica preguntas preguntandote por timing, registro afectado y mantenimiento. Si fallas una pregunta, escribe si confundiste tipo de flow, condicion de entrada, before-save, after-save o schedule.
- Trailhead: Get Started with Flow Builder
- Trailhead: Record-Triggered Flows
- Trailhead: Add a Scheduled Task to Your Flow
- Guia completa de Salesforce Platform Administrator
- Practicar preguntas de Platform Administrator
BlueForce no esta afiliado a Salesforce. Esta guia es contenido editorial original basado en experiencia de estudio, objetivos publicos y recursos oficiales.