Praxis Academy
Inicio › Platform Administrator II › Process Automation

Preguntas de práctica Platform Administrator II: Process Automation

Process Automation vale 20% del examen Salesforce Certified Platform Administrator II. Cubre tipos de flow, manejo de errores, orden de ejecución y aprobaciones. Resuelve estas 8 preguntas gratis y abre cada respuesta para ver por qué cada opción es correcta o incorrecta.

01

En un Record-Triggered Flow sobre Opportunity, se colocan un elemento Get Records y un elemento Update Records antes del primer Decision element. ¿Cuál es el mayor riesgo de este diseño?

  1. El flow fallará, porque Flow Builder no permite Get Records y Update Records en la misma ruta.
  2. Ejecutar DML (Update Records) antes de un Decision element hace que cada registro que dispara el flow realice la actualización, se cumplan o no las condiciones para ello, consumiendo innecesariamente los límites de gobernador de DML.
  3. Get Records devolverá solo los registros que el usuario en ejecución puede ver, lo que provoca lecturas incompletas en contextos automatizados.
  4. Update Records creará registros duplicados si el flow se dispara más de una vez para el mismo registro.
Ver respuesta

Respuesta: B

A. El flow fallará, porque Flow Builder no permite Get Records y Update Records en la misma ruta.Incorrecta. No existe esa restricción; ambos elementos pueden estar en la misma ruta.
B. Ejecutar DML (Update Records) antes de un Decision element hace que cada registro que dispara el flow realice la actualización, se cumplan o no las condiciones para ello, consumiendo innecesariamente los límites de gobernador de DML. ✓Correcta. Sin un Decision temprano, el DML se ejecuta para cada registro que dispara el flow aunque no haya nada que cambiar, lo que pone en riesgo los límites de gobernador.
C. Get Records devolverá solo los registros que el usuario en ejecución puede ver, lo que provoca lecturas incompletas en contextos automatizados.Incorrecta. Los record-triggered flows se ejecutan en contexto de sistema de forma predeterminada y no se limitan al acceso del usuario en ejecución.
D. Update Records creará registros duplicados si el flow se dispara más de una vez para el mismo registro.Incorrecta. Update Records modifica registros existentes y nunca crea duplicados; la recursión es un tema aparte.

Por qué: La mejor práctica en Flow Builder es filtrar con Decision elements al principio y ejecutar DML solo cuando sea necesario. Poner DML antes del Decision provoca actualizaciones innecesarias y consume límites de gobernador. El orden recomendado es criterios de entrada, luego Decision, luego elementos DML.

02

Para un Account dado, un flujo debe obtener todos los Contact relacionados, recorrerlos y enviar una notificación personalizada solo a los Contact cuyo correo termine en '@enterprise.com'. ¿Qué dos elementos de Flow son necesarios? (Elija 2)

  1. Un elemento Get Records que cargue todos los Contact del Account en una variable de colección de registros.
  2. Un elemento Loop con un Decision element dentro que verifique si el correo de cada Contact termina en '@enterprise.com' antes de enviar la notificación.
  3. Un elemento Subflow que llame a otro flujo para revisar el dominio de correo de cada Contact.
  4. Un elemento Create Records dentro del bucle que registre cada Contact notificado.
Ver respuesta

Respuesta: A, B

A. Un elemento Get Records que cargue todos los Contact del Account en una variable de colección de registros. ✓Correcta. Get Records consulta los Contact filtrados por AccountId y los guarda en una colección para el Loop.
B. Un elemento Loop con un Decision element dentro que verifique si el correo de cada Contact termina en '@enterprise.com' antes de enviar la notificación. ✓Correcta. El Loop recorre la colección y el Decision element interno revisa el dominio (por ejemplo, con una condición 'termina en' o una fórmula) para cada Contact.
C. Un elemento Subflow que llame a otro flujo para revisar el dominio de correo de cada Contact.Incorrecta. Un Subflow es posible pero innecesario; un Decision element dentro del bucle principal es más sencillo.
D. Un elemento Create Records dentro del bucle que registre cada Contact notificado.Incorrecta. Registrar los envíos no forma parte del requisito, así que Create Records no es necesario.

Por qué: El patrón es Get Records (colección de Contact) -> Loop (un Contact a la vez) -> Decision (revisión del dominio) -> Send Custom Notification en el resultado verdadero. Get Records aporta los datos; Loop más Decision aportan la iteración y la lógica condicional.

03

Cada vez que el Stage de una Opportunity pasa a 'Closed Won,' debe crearse automáticamente un Contract relacionado con campos llenados desde la Opportunity. ¿Qué solución declarativa se recomienda?

  1. Agregar una Validation Rule en Opportunity que pida a los usuarios crear el Contract manualmente cuando Stage = 'Closed Won.'
  2. Configurar un Record-Triggered Flow before-save en Opportunity que se ejecute cuando Stage cambie a 'Closed Won' y cree el Contract.
  3. Crear un Record-Triggered Flow after-save en Opportunity que se dispare cuando Stage cambie a 'Closed Won' y use un elemento Create Records para generar el Contract con valores tomados de la Opportunity.
  4. Colocar una Quick Action en el Page Layout de Opportunity para que los representantes creen un Contract prellenado con un solo clic.
Ver respuesta

Respuesta: C

A. Agregar una Validation Rule en Opportunity que pida a los usuarios crear el Contract manualmente cuando Stage = 'Closed Won.'Incorrecta. Las Validation Rules bloquean datos incorrectos; no pueden crear registros relacionados.
B. Configurar un Record-Triggered Flow before-save en Opportunity que se ejecute cuando Stage cambie a 'Closed Won' y cree el Contract.Incorrecta. Los flujos before-save se ejecutan antes de confirmar el registro y no pueden hacer DML en otros registros, como un Contract nuevo.
C. Crear un Record-Triggered Flow after-save en Opportunity que se dispare cuando Stage cambie a 'Closed Won' y use un elemento Create Records para generar el Contract con valores tomados de la Opportunity. ✓Correcta. Un flujo after-save puede crear el Contract con Create Records y llenarlo con datos de la Opportunity que lo disparó.
D. Colocar una Quick Action en el Page Layout de Opportunity para que los representantes creen un Contract prellenado con un solo clic.Incorrecta. Una Quick Action puede prellenar valores, pero requiere que un usuario haga clic; el requisito es una creación totalmente automática.

Por qué: Los Record-Triggered Flows after-save realizan DML en otros registros una vez guardado el registro que los dispara. La condición de entrada detecta el cambio de Stage a 'Closed Won,' y Create Records genera el Contract con los valores mapeados (Account, fechas, monto). Los flujos before-save no pueden crear ni actualizar otros registros.

04

Los usuarios nuevos creados con un Profile específico deben agregarse automáticamente a un grupo público determinado. ¿Qué herramienta declarativa puede automatizarlo?

  1. Un Record-Triggered Flow en User que se ejecute al crearlo y use un elemento Create Records de 'Group Member' para agregar al usuario al grupo.
  2. Una Auto-Assignment Rule que coloque a los usuarios nuevos con ese Profile en el grupo público elegido.
  3. Un trigger Apex en User que se dispare al crearlo e inserte un registro GroupMember que vincule al usuario con el grupo.
  4. No existe una opción totalmente declarativa para la membresía en grupos públicos según el Profile; se debe usar un Platform Event-triggered Flow o Apex, o agregar a los usuarios manualmente después de crearlos.
Ver respuesta

Respuesta: D

A. Un Record-Triggered Flow en User que se ejecute al crearlo y use un elemento Create Records de 'Group Member' para agregar al usuario al grupo.Incorrecta. Según la fuente, el elemento Create Records estándar en un flujo disparado por User no puede insertar registros GroupMember de forma confiable por restricciones de DML en ese contexto.
B. Una Auto-Assignment Rule que coloque a los usuarios nuevos con ese Profile en el grupo público elegido.Incorrecta. Salesforce no tiene una 'Auto-Assignment Rule' para la membresía en grupos públicos.
C. Un trigger Apex en User que se dispare al crearlo e inserte un registro GroupMember que vincule al usuario con el grupo.Incorrecta. Un trigger Apex funcionaría, pero es código, y la pregunta pide una herramienta declarativa.
D. No existe una opción totalmente declarativa para la membresía en grupos públicos según el Profile; se debe usar un Platform Event-triggered Flow o Apex, o agregar a los usuarios manualmente después de crearlos. ✓Correcta. Según la fuente, es una limitación declarativa conocida; las vías prácticas son Apex, un enfoque basado en Platform Events o la asignación manual.

Por qué: Según la fuente, agregar automáticamente usuarios nuevos a grupos públicos es una limitación declarativa: los flujos disparados en User tienen restricciones de DML sobre GroupMember. Las opciones sugeridas son un trigger Apex en User, un proceso basado en Platform Events o la asignación manual después de la creación.

05

Un flujo debe seguir una ruta distinta según el nivel de ingresos anuales del Account que lo dispara: Bajo (<$1M), Medio ($1M-$10M) o Alto (>$10M). ¿Cuál es la forma recomendada de construir esta ramificación?

  1. Crear tres Record-Triggered Flows separados, uno por nivel, cada uno con criterios de entrada para su rango de ingresos.
  2. Usar un solo Decision element con tres resultados (Bajo, Medio, Alto), cada uno evaluando su rango de Annual Revenue, y dirigir cada resultado a su propia lógica.
  3. Poner fórmulas If-Else anidadas en un solo elemento Assignment para calcular el nivel en una variable y luego usar esa variable más adelante en el flujo.
  4. Usar un elemento Loop que se ejecute tres veces, evaluando un nivel de ingresos distinto en cada pasada y ejecutando la lógica correspondiente.
Ver respuesta

Respuesta: B

A. Crear tres Record-Triggered Flows separados, uno por nivel, cada uno con criterios de entrada para su rango de ingresos.Incorrecta. Repartir una misma lógica en tres flujos aumenta el mantenimiento y hace la automatización más difícil de seguir y depurar.
B. Usar un solo Decision element con tres resultados (Bajo, Medio, Alto), cada uno evaluando su rango de Annual Revenue, y dirigir cada resultado a su propia lógica. ✓Correcta. Un solo Decision element admite varios resultados, cada uno con sus condiciones, y el resultado Default atrapa lo que quede.
C. Poner fórmulas If-Else anidadas en un solo elemento Assignment para calcular el nivel en una variable y luego usar esa variable más adelante en el flujo.Incorrecta. Los elementos Assignment asignan valores; no ramifican el flujo. El Decision element es la herramienta correcta para rutas distintas.
D. Usar un elemento Loop que se ejecute tres veces, evaluando un nivel de ingresos distinto en cada pasada y ejecutando la lógica correspondiente.Incorrecta. Los Loop recorren colecciones, no una lista de condiciones.

Por qué: El Decision element es la herramienta de ramificación de Flow Builder. Evalúa los resultados en orden y sigue el primero cuyas condiciones se cumplen. Tres resultados con nombre (Bajo, Medio, Alto) más el resultado Default dan una estructura limpia de varias ramas basada en campos, variables o fórmulas.

06

Un flujo tiene una ruta programada que debe dar seguimiento a las Opportunity 7 días después de su Close Date, pero algunas Opportunity que califican nunca se procesan. El administrador descubre que sus Close Date ya estaban en el pasado cuando se activó el flujo. ¿Qué lo explica mejor?

  1. Las rutas programadas de los Record-Triggered Flows solo evalúan registros creados DESPUÉS de activar el flujo; los registros que ya existían antes de la activación no se evalúan de forma retroactiva.
  2. El administrador debe iniciar manualmente la ruta programada de cada Opportunity con un botón personalizado.
  3. Las rutas programadas solo existen en Salesforce Unlimited Edition y no se admiten en Enterprise Edition.
  4. El flujo debe reactivarse cada 24 horas para que sus rutas programadas sigan procesándose.
Ver respuesta

Respuesta: A

A. Las rutas programadas de los Record-Triggered Flows solo evalúan registros creados DESPUÉS de activar el flujo; los registros que ya existían antes de la activación no se evalúan de forma retroactiva. ✓Correcta. Solo los registros creados o actualizados después de la activación se encolan en la ruta programada; los anteriores requieren un Scheduled Flow que los consulte.
B. El administrador debe iniciar manualmente la ruta programada de cada Opportunity con un botón personalizado.Incorrecta. Las rutas programadas se ejecutan automáticamente y no necesitan que un usuario las active registro por registro.
C. Las rutas programadas solo existen en Salesforce Unlimited Edition y no se admiten en Enterprise Edition.Incorrecta. Las rutas programadas están disponibles en varias ediciones, incluidas Enterprise y Unlimited.
D. El flujo debe reactivarse cada 24 horas para que sus rutas programadas sigan procesándose.Incorrecta. Un flujo activo sigue procesando sus rutas programadas sin necesidad de reactivarlo periódicamente.

Por qué: Las rutas programadas solo se encolan cuando un registro se crea o actualiza después de que el flujo está activo y cumple el disparador. Los registros existentes no se toman de forma retroactiva. Para ponerse al día con registros anteriores, use un Scheduled Flow aparte que los consulte y procese.

07

En un flujo before-save sobre Opportunity, el administrador debe detener el guardado cuando no se cumple una regla de negocio (por ejemplo, Stage es 'Closed Won' pero Close Date está en el futuro). ¿Cómo debe hacerse dentro del flujo?

  1. Usar un Decision element para evaluar la condición y, en el resultado FALSE, agregar un elemento Update Records que marque una casilla personalizada 'Block_Save__c', lo que dispara una Validation Rule que bloquea el guardado.
  2. Omitir el flujo y usar una Validation Rule en Opportunity, ya que las Validation Rules son la función diseñada para bloquear guardados.
  3. Usar un Decision element en el flujo before-save para evaluar la condición y, en la ruta que falla, agregar un elemento 'Custom Error' (o 'Error Message') que muestre un mensaje de error e impida guardar el registro.
  4. Forzar un 'Fault' colocando un elemento Create Records en la ruta de error, generando un evento de fallo que bloquee el guardado.
Ver respuesta

Respuesta: C

A. Usar un Decision element para evaluar la condición y, en el resultado FALSE, agregar un elemento Update Records que marque una casilla personalizada 'Block_Save__c', lo que dispara una Validation Rule que bloquea el guardado.Incorrecta. Este rodeo indirecto es innecesariamente complejo; los flujos before-save no usan Update Records para esto y no se necesita una Validation Rule para bloquear el guardado.
B. Omitir el flujo y usar una Validation Rule en Opportunity, ya que las Validation Rules son la función diseñada para bloquear guardados.Incorrecta. Una Validation Rule puede bloquear guardados, pero la pregunta pide cómo hacerlo dentro del flujo.
C. Usar un Decision element en el flujo before-save para evaluar la condición y, en la ruta que falla, agregar un elemento 'Custom Error' (o 'Error Message') que muestre un mensaje de error e impida guardar el registro. ✓Correcta. El elemento Custom Error muestra un mensaje y bloquea el guardado, como un error de Validation Rule, pero permite lógica más compleja.
D. Forzar un 'Fault' colocando un elemento Create Records en la ruta de error, generando un evento de fallo que bloquee el guardado.Incorrecta. Las rutas de fallo son para errores inesperados; forzar un fallo a propósito no es la manera de validar. Use Custom Error.

Por qué: El elemento 'Custom Error' en los record-triggered flows muestra un mensaje claro y bloquea el guardado cuando una condición no se cumple, de forma parecida a una Validation Rule. Es útil cuando la verificación requiere condiciones complejas, consultas a registros relacionados o cálculos difíciles de expresar en una sola fórmula de Validation Rule.

08

La empresa quiere enviar una alerta de 'bandera roja' al propietario de cualquier Opportunity que lleve más de 30 días sin actividad registrada (tareas o eventos). ¿Qué tipo de Flow y disparador encajan mejor?

  1. Un Record-Triggered Flow en Opportunity que se ejecute con 'record is updated' y tenga una ruta programada 30 días después de la Last Activity Date.
  2. Un Platform Event-triggered Flow que se dispare al publicarse un platform event de Last Activity Date y notifique al propietario.
  3. Un Autolaunched Flow detrás de un botón personalizado en la página de Opportunity que los representantes presionen para revisar su propia actividad.
  4. Un Scheduled Flow que se ejecute a diario, consulte todas las Opportunity cuya Last Activity Date tenga más de 30 días (o esté vacía) y cuyo Stage no sea Closed, y notifique al propietario de cada coincidencia.
Ver respuesta

Respuesta: D

A. Un Record-Triggered Flow en Opportunity que se ejecute con 'record is updated' y tenga una ruta programada 30 días después de la Last Activity Date.Incorrecta. Una ruta programada al actualizar solo arranca cuando se edita el registro; una Opportunity inactiva puede no actualizarse nunca y nunca entraría en la ruta.
B. Un Platform Event-triggered Flow que se dispare al publicarse un platform event de Last Activity Date y notifique al propietario.Incorrecta. Salesforce no tiene un platform event estándar de 'Last Activity Date'; Last Activity Date es un campo estándar.
C. Un Autolaunched Flow detrás de un botón personalizado en la página de Opportunity que los representantes presionen para revisar su propia actividad.Incorrecta. Un botón requiere que un usuario actúe, así que no es una alerta automática.
D. Un Scheduled Flow que se ejecute a diario, consulte todas las Opportunity cuya Last Activity Date tenga más de 30 días (o esté vacía) y cuyo Stage no sea Closed, y notifique al propietario de cada coincidencia. ✓Correcta. Un Scheduled Flow diario puede evaluar todas las Opportunity para detectar 30 días de inactividad, se hayan actualizado o no, y avisar a cada propietario.

Por qué: Un Scheduled Flow diario es adecuado para alertas proactivas basadas en tiempo sobre muchos registros. Encuentra las Opportunity abiertas cuya Last Activity Date tiene más de 30 días y avisa a cada propietario. Es más confiable que una ruta programada, que solo se inicia cuando un registro se crea o actualiza.

Descubre si estás listo para aprobar

Haz el diagnóstico gratis de Platform Administrator II: 20 preguntas, sin cuenta. Después desbloquea las 180 preguntas, los exámenes de práctica completos y la guía de estudio.

Hacer el diagnóstico gratisVer planes

Otras secciones de este examen