Praxis Academy
Inicio › Platform App Builder › Business Logic and Process Automation

Preguntas de práctica Platform App Builder: Business Logic and Process Automation

Business Logic and Process Automation vale 32% del examen Salesforce Certified Platform App Builder. Cubre Flow, validation rules, fórmulas y aprobaciones. Resuelve estas 14 preguntas gratis y abre cada respuesta para ver por qué cada opción es correcta o incorrecta.

01

Una empresa de dispositivos médicos quiere que el campo de fecha Stage_Last_Changed__c de una oportunidad se registre cada vez que cambie StageName. ¿Qué debe construir el Platform App Builder?

  1. Un Record-Triggered Flow before-save en Opportunity que establezca Stage_Last_Changed__c en la fecha de hoy cada vez que cambie StageName
  2. Un Record-Triggered Flow after-save con una ruta programada que establezca Stage_Last_Changed__c en la fecha de hoy una hora después del cambio
  3. Un proceso de aprobación en Opportunity que use Update Records para establecer Stage_Last_Changed__c en la fecha de hoy cada vez que cambie StageName
  4. Un flujo autolanzado iniciado desde un botón personalizado, en el que el usuario hace clic después de cambiar StageName, para establecer Stage_Last_Changed__c en la fecha de hoy
Ver respuesta

Respuesta: A

A. Un Record-Triggered Flow before-save en Opportunity que establezca Stage_Last_Changed__c en la fecha de hoy cada vez que cambie StageName ✓Correcta. Un flujo before-save actualiza el registro que lo dispara sin DML adicional, lo que lo convierte en la forma más eficiente de registrar la fecha.
B. Un Record-Triggered Flow after-save con una ruta programada que establezca Stage_Last_Changed__c en la fecha de hoy una hora después del cambioIncorrecta. La ruta programada retrasa la actualización una hora y es menos eficiente que una actualización before-save.
C. Un proceso de aprobación en Opportunity que use Update Records para establecer Stage_Last_Changed__c en la fecha de hoy cada vez que cambie StageNameIncorrecta. Los procesos de aprobación envían registros a aprobación; no están pensados para registrar un campo en cada cambio de etapa.
D. Un flujo autolanzado iniciado desde un botón personalizado, en el que el usuario hace clic después de cambiar StageName, para establecer Stage_Last_Changed__c en la fecha de hoyIncorrecta. Un flujo lanzado por botón depende de que el usuario recuerde hacer clic, así que no es automático.

Por qué: Solo hay que cambiar un campo del registro que dispara el flujo, por lo que un flujo before-save es ideal: actualiza el registro mientras se guarda, sin DML adicional. Salesforce recomienda los flujos before-save para actualizar campos del mismo registro porque son la opción más rápida.

02

Un Platform App Builder descubre que varias cuentas creadas mediante la conversión de leads carecen de información que se esperaba que las reglas de validación de Account hicieran cumplir. ¿Qué explica este problema?

  1. Las reglas de validación de Account no se evalúan en los registros creados mediante la conversión de leads.
  2. La configuración de leads permite que los usuarios omitan deliberadamente las reglas de validación.
  3. En la configuración de leads, la opción para exigir validación en leads convertidos está desmarcada.
  4. Las reglas de validación de Lead no se evalúan en los registros mientras se convierten.
Ver respuesta

Respuesta: D

A. Las reglas de validación de Account no se evalúan en los registros creados mediante la conversión de leads.Incorrecta. Las reglas de validación de Account sí se ejecutan en los registros creados por la conversión de leads.
B. La configuración de leads permite que los usuarios omitan deliberadamente las reglas de validación.Incorrecta. No existe ninguna configuración de leads que permita a los usuarios omitir deliberadamente las reglas de validación.
C. En la configuración de leads, la opción para exigir validación en leads convertidos está desmarcada.Incorrecta. 'Require Validation for Converted Leads' controla la validación y los triggers durante la conversión y, según la fuente, no explica aquí los datos faltantes en las cuentas.
D. Las reglas de validación de Lead no se evalúan en los registros mientras se convierten. ✓Correcta. Las reglas de validación de Lead no se disparan durante la conversión, así que los leads incompletos se convierten y trasladan esos huecos a las nuevas cuentas.

Por qué: La brecha está del lado de Lead: las reglas de validación de leads no se aplican durante la conversión, así que un lead al que le faltan datos aún puede convertirse y trasladar esos datos faltantes a la nueva cuenta, donde las reglas de validación de Account nunca tienen oportunidad de detectarlo.

03

Una empresa necesita recopilar información de un usuario y luego usarla para actualizar un registro de Account relacionado. ¿Qué combinación de tipo de flujo y elemento debe usar el Platform App Builder?

  1. Flujo autolanzado con un elemento Screen y un elemento Update Records
  2. Record-Triggered Flow con un elemento Screen y un elemento Create Records
  3. Flujo desencadenado por programación con un elemento Assignment y un elemento Create Records
  4. Screen Flow con elementos Screen y un elemento Update Records
Ver respuesta

Respuesta: D

A. Flujo autolanzado con un elemento Screen y un elemento Update RecordsIncorrecta. Los flujos autolanzados no tienen interfaz de usuario, así que no pueden incluir elementos Screen.
B. Record-Triggered Flow con un elemento Screen y un elemento Create RecordsIncorrecta. Los Record-Triggered Flows no pueden mostrar pantallas, y la necesidad es actualizar, no crear.
C. Flujo desencadenado por programación con un elemento Assignment y un elemento Create RecordsIncorrecta. Los flujos desencadenados por programación se ejecutan sin un usuario, y Create Records no actualiza la cuenta.
D. Screen Flow con elementos Screen y un elemento Update Records ✓Correcta. Los elementos Screen recopilan la información y luego Update Records la guarda en la cuenta relacionada.

Por qué: Recopilar información de un usuario requiere un Screen Flow, el único tipo que muestra pantallas interactivas. Los elementos Screen recopilan la información y luego un elemento Update Records escribe esos valores en la Account relacionada.

04

Una empresa debe impedir que los usuarios de ventas guarden Opportunity Products cuyo descuento supere el 15%. ¿Cómo debe configurarse esto?

  1. Una regla de validación en el registro de Opportunity Product
  2. Un proceso de aprobación disparado por actualizaciones en Opportunity Products
  3. Una regla de validación en el registro de Opportunity
  4. Una alerta Big Deal en el registro de Opportunity
Ver respuesta

Respuesta: A

A. Una regla de validación en el registro de Opportunity Product ✓Correcta. El descuento está en Opportunity Product, así que una regla de validación ahí bloquea las partidas que superen el 15%.
B. Un proceso de aprobación disparado por actualizaciones en Opportunity ProductsIncorrecta. Un proceso de aprobación revisa un registro después de guardarlo; no impide el guardado.
C. Una regla de validación en el registro de OpportunityIncorrecta. El campo de descuento está en Opportunity Product, no en Opportunity.
D. Una alerta Big Deal en el registro de OpportunityIncorrecta. Las alertas Big Deal notifican sobre oportunidades grandes; no bloquean guardados.

Por qué: El descuento se almacena en cada partida (Opportunity Product), no en la Opportunity. Una regla de validación en Opportunity Product se ejecuta al guardar y rechaza cualquier partida con un descuento mayor al 15%.

05

Una empresa necesita una automatización que se ejecute cada domingo a las 2:00 a.m. Debe establecer en True la casilla personalizada Inactive__c en todas las cuentas cuyo campo estándar Last Activity Date tenga más de 90 días de antigüedad. Se deben evaluar todos los registros de cuentas y el trabajo debe repetirse semanalmente. ¿Qué diseño de flujo debe elegir el Platform App Builder?

  1. Un Record-Triggered Flow en Account con una ruta programada que se ejecute 90 días después del Last Activity Date de cada Account
  2. Un flujo autolanzado que un app builder programa para cada domingo a las 2:00 a.m.
  3. Un flujo desencadenado por programación en Account con frecuencia Weekly, hora de inicio el domingo a las 2:00 a.m. y condiciones de entrada que seleccionen las Accounts cuyo Last Activity Date tenga más de 90 días
  4. Un flujo desencadenado por programación en Account con frecuencia Once para el próximo domingo a las 2:00 a.m. y condiciones de entrada que seleccionen las Accounts cuyo Last Activity Date tenga más de 90 días
Ver respuesta

Respuesta: C

A. Un Record-Triggered Flow en Account con una ruta programada que se ejecute 90 días después del Last Activity Date de cada AccountIncorrecta. Las rutas programadas se disparan por registro a partir de un evento, no como un barrido semanal de todas las cuentas.
B. Un flujo autolanzado que un app builder programa para cada domingo a las 2:00 a.m.Incorrecta. Un flujo autolanzado simple no se programa; esa es la función de un flujo desencadenado por programación.
C. Un flujo desencadenado por programación en Account con frecuencia Weekly, hora de inicio el domingo a las 2:00 a.m. y condiciones de entrada que seleccionen las Accounts cuyo Last Activity Date tenga más de 90 días ✓Correcta. Un flujo desencadenado por programación semanal, el domingo a las 2:00 a.m., con condiciones de entrada sobre Last Activity Date evalúa todas las cuentas que califican.
D. Un flujo desencadenado por programación en Account con frecuencia Once para el próximo domingo a las 2:00 a.m. y condiciones de entrada que seleccionen las Accounts cuyo Last Activity Date tenga más de 90 díasIncorrecta. Una frecuencia 'Once' se ejecuta una sola vez, no cada domingo.

Por qué: Un flujo desencadenado por programación está diseñado para ejecutarse con un horario recurrente sobre un lote de registros. La frecuencia Weekly a partir del domingo a las 2:00 a.m. coincide con el horario, y las condiciones de entrada incluyen en cada ejecución todas las Accounts que cumplen la regla de 90 días.

06

Un centro de soporte que opera las 24 horas necesita un asistente guiado que lleve a los representantes de servicio al cliente por un guion estándar de solución de problemas. El proceso debe recopilar información del usuario en varios puntos y crear un caso de seguimiento al terminar. ¿Qué tipo de flujo proporciona esta interfaz interactiva?

  1. Screen Flow
  2. Flujo desencadenado por programación (Schedule-Triggered Flow)
  3. Record-Triggered Flow
  4. Flujo desencadenado por Platform Event
Ver respuesta

Respuesta: A

A. Screen Flow ✓Correcta. Un Screen Flow guía a los representantes por el guion, captura información en cada pantalla y crea el caso de seguimiento al final.
B. Flujo desencadenado por programación (Schedule-Triggered Flow)Incorrecta. Los flujos desencadenados por programación se ejecutan en segundo plano sin pantallas.
C. Record-Triggered FlowIncorrecta. Los Record-Triggered Flows se ejecutan con cambios en los registros, sin pantallas.
D. Flujo desencadenado por Platform EventIncorrecta. Los flujos desencadenados por Platform Event se ejecutan cuando llegan eventos y no tienen interfaz de usuario.

Por qué: Un Screen Flow es el único tipo de flujo que muestra pantallas interactivas para recopilar información del usuario. Puede construirse como un asistente de varios pasos que sigue el guion y terminar con un elemento Create Records para crear el caso de seguimiento.

07

Antes de que una Opportunity pueda pasar a la etapa Qualified, una empresa de ciencias de la vida exige que el campo Expected_Close_Date__c tenga un valor. ¿Qué opción permite a un Platform App Builder aplicar esto de la forma más eficiente?

  1. Page Layout
  2. Validation Rule
  3. Autocompletado de Lookup
  4. Record-Triggered Flow
Ver respuesta

Respuesta: B

A. Page LayoutIncorrecta. Marcar el campo como obligatorio en un Page Layout lo vuelve obligatorio en todas las etapas, no solo en Qualified.
B. Validation Rule ✓Correcta. Una fórmula detecta Stage = Qualified con Expected_Close_Date__c vacío e impide el guardado.
C. Autocompletado de LookupIncorrecta. El autocompletado de Lookup solo agiliza la búsqueda de registros relacionados; no aplica ninguna regla.
D. Record-Triggered FlowIncorrecta. Un flujo podría lograrlo, pero una Validation Rule es más simple y está diseñada exactamente para esto.

Por qué: El requisito es condicional: la fecha es obligatoria solo cuando el Stage pasa a Qualified, y la verificación debe hacerse al guardar. Una Validation Rule resuelve esto de forma nativa. Una sola fórmula puede comprobar que Stage sea Qualified y que Expected_Close_Date__c esté vacío, y entonces detener el guardado con un error. Se ejecuta en cada guardado sin automatización adicional que mantener, lo que la convierte en la herramienta más simple y diseñada específicamente para campos obligatorios condicionales. Referencia: Validation Rules

08

Un Platform App Builder de un fabricante de equipo de laboratorio está creando un Record-Triggered Flow en Opportunity. Cuando se crea una oportunidad, el flujo debe asignar un valor predeterminado al campo Stage según el Industry de la Account relacionada. El objetivo es la configuración más eficiente. ¿Qué configuración debe usarse?

  1. Un Record-Triggered Flow after-save con un elemento Assignment que establezca Record.Stage según Record.Account.Industry
  2. Un Record-Triggered Flow before-save con un elemento Assignment que establezca Record.Stage según Record.Account.Industry
  3. Un Record-Triggered Flow after-save con un elemento Update Records que establezca la etapa de la Opportunity según el Industry de la Account
  4. Un Record-Triggered Flow before-save con un elemento Update Records que establezca la etapa de la Opportunity según el Industry de la Account
Ver respuesta

Respuesta: B

A. Un Record-Triggered Flow after-save con un elemento Assignment que establezca Record.Stage según Record.Account.IndustryIncorrecta. En un flujo after-save, asignar valores a $Record no se guarda sin un Update Records adicional.
B. Un Record-Triggered Flow before-save con un elemento Assignment que establezca Record.Stage según Record.Account.Industry ✓Correcta. Antes del guardado, un Assignment establece $Record.StageName a partir del Industry de la Account sin DML adicional.
C. Un Record-Triggered Flow after-save con un elemento Update Records que establezca la etapa de la Opportunity según el Industry de la AccountIncorrecta. Funciona, pero el segundo guardado lo hace menos eficiente.
D. Un Record-Triggered Flow before-save con un elemento Update Records que establezca la etapa de la Opportunity según el Industry de la AccountIncorrecta. Los flujos before-save cambian el registro que los activa mediante Assignment, no con Update Records.

Por qué: Solo cambia un campo de la Opportunity que activa el flujo, y la pregunta pide el enfoque más eficiente, no solo uno que funcione. Un flujo before-save modifica los campos del registro que lo activa antes de que se escriban, por lo que no se necesita un guardado adicional. En ese contexto, un elemento Assignment sobre $Record es la forma más ligera de establecer Stage. Un flujo after-save requeriría una segunda actualización DML. Las buenas prácticas de Salesforce recomiendan flujos before-save con Assignment siempre que solo cambien campos del registro que activa el flujo. Referencia: Before-Save Record-Triggered Flows

09

Un sistema de inventario externo envía una notificación de mensaje segura cada vez que un artículo se queda sin existencias. En Salesforce, el Platform App Builder debe crear un proceso que escuche ese payload de mensaje específico y cree de inmediato una tarea para compras. ¿Qué tipo de flujo está diseñado para ejecutarse en el momento en que llega este mensaje externo?

  1. Record-Triggered Flow
  2. Flujo autolanzado sin desencadenador
  3. Screen Flow
  4. Platform Event-Triggered Flow
Ver respuesta

Respuesta: D

A. Record-Triggered FlowIncorrecta. Los Record-Triggered Flows responden a cambios en registros de Salesforce, no a mensajes de eventos entrantes.
B. Flujo autolanzado sin desencadenadorIncorrecta. Un flujo autolanzado sin desencadenador debe ser invocado por otro elemento y no puede escuchar mensajes.
C. Screen FlowIncorrecta. Un usuario debe iniciar un Screen Flow.
D. Platform Event-Triggered Flow ✓Correcta. Se inicia cuando llega el mensaje del evento externo y puede crear la Task de compras.

Por qué: Un sistema externo publica un mensaje estructurado, y Salesforce debe reaccionar al instante creando una tarea de compras. Los Platform Events son la forma en que Salesforce recibe mensajes estructurados y seguros de sistemas externos en tiempo real. Un Platform Event-Triggered Flow se inicia en cuanto se recibe un mensaje de ese tipo de evento, por lo que puede crear la Task de compras de inmediato. Referencia: Start a Flow with a Platform Event

10

Un empleado de una empresa de equipos solares envió una oportunidad para que la aprobara su gerente. ¿Qué sucede si el empleado intenta después editar el campo de descripción?

  1. El usuario solo puede editar el campo de descripción.
  2. El usuario ve una notificación de 'Record Lock'.
  3. El usuario puede editar el nombre, pero no la descripción.
  4. El usuario ve que ahora el gerente es el propietario del registro.
Ver respuesta

Respuesta: B

A. El usuario solo puede editar el campo de descripción.Incorrecta. El bloqueo impide que el usuario edite la descripción.
B. El usuario ve una notificación de 'Record Lock'. ✓Correcta. El envío bloquea el registro, así que un intento de edición genera un mensaje de registro bloqueado.
C. El usuario puede editar el nombre, pero no la descripción.Incorrecta. El bloqueo impide que quien envió el registro edite cualquier campo, incluido el nombre.
D. El usuario ve que ahora el gerente es el propietario del registro.Incorrecta. La propiedad no cambia cuando un registro se envía a aprobación.

Por qué: La pregunta evalúa el comportamiento predeterminado que se aplica a un registro una vez que entra en un proceso de aprobación. De forma predeterminada, la acción de envío inicial bloquea el registro para que quien lo envió no pueda cambiar los datos en revisión. Mientras está pendiente, el registro es de solo lectura para la mayoría de los usuarios (normalmente todos excepto los administradores y, según la configuración, el aprobador). Si el empleado intenta editar y guardar cualquier campo, Salesforce bloquea el guardado y muestra un mensaje indicando que el registro está bloqueado. Referencia: Record Locking in Flow Approval Processes | Salesforce Help

11

Una empresa de biotecnología está diseñando un proceso de incorporación de clientes que involucra a varios usuarios, múltiples pasos y trabajo repartido en distintos días. ¿Qué herramienta de automatización es la más adecuada?

  1. Entitlement Process
  2. Flow Orchestration
  3. Lightning Web Component personalizado
  4. Screen Flow
Ver respuesta

Respuesta: B

A. Entitlement ProcessIncorrecta. Los Entitlement Processes dan seguimiento a hitos de soporte y SLA, no a trabajo de incorporación.
B. Flow Orchestration ✓Correcta. Orquesta trabajo de varios pasos a través de etapas, usuarios y días.
C. Lightning Web Component personalizadoIncorrecta. Un LWC personalizado implica código y no coordina trabajo de varios usuarios a lo largo del tiempo.
D. Screen FlowIncorrecta. Un Screen Flow atiende a un solo usuario en una sola sesión.

Por qué: Aquí la incorporación abarca a varias personas y varios días, no a un solo usuario en una sola sesión. Flow Orchestration está diseñado para coordinar procesos de larga duración con múltiples usuarios. Agrupa flujos, incluidos Screen Flows, en etapas y pasos, asigna cada paso al usuario adecuado y da seguimiento al avance general a lo largo de los días. Referencia: Flow Orchestration

12

Los usuarios deben completar el campo Reason Lost cada vez que establecen la etapa de una Opportunity en Closed Lost. ¿Cómo debe implementar esto un Platform App Builder?

  1. Hacer que Reason Lost sea obligatorio en el editor de Page Layout.
  2. Hacer que Reason Lost sea obligatorio con Dynamic Forms y sin criterios de filtro.
  3. Marcar "Reason Lost" como obligatorio a nivel de campo.
  4. Crear una Validation Rule que aplique el requisito condicional.
Ver respuesta

Respuesta: D

A. Hacer que Reason Lost sea obligatorio en el editor de Page Layout.Incorrecta. La obligatoriedad a nivel de layout aplica en todas las etapas.
B. Hacer que Reason Lost sea obligatorio con Dynamic Forms y sin criterios de filtro.Incorrecta. Sin criterios de filtro, el campo siempre es obligatorio.
C. Marcar "Reason Lost" como obligatorio a nivel de campo.Incorrecta. La obligatoriedad a nivel de campo aplica a cada guardado en todas partes.
D. Crear una Validation Rule que aplique el requisito condicional. ✓Correcta. La regla exige Reason Lost solo cuando la etapa es Closed Lost.

Por qué: Reason Lost es obligatorio solo cuando Stage es Closed Lost, no en cada guardado. Una Validation Rule como ISPICKVAL(StageName, "Closed Lost") && ISBLANK(Reason_Lost__c) exige el campo solo bajo esa condición y bloquea el guardado hasta que se complete. Las demás opciones hacen que el campo sea siempre obligatorio. Referencia: Define Validation Rules

13

Una empresa de equipos solares está creando un nuevo proceso de aprobación de oportunidades y quiere que se ejecuten varias acciones en el envío inicial. ¿Qué tres tipos de acción puede usar un app builder en el proceso de aprobación? (Elija 3)

  1. Invocable Flow
  2. Decision Element
  3. Email Alert
  4. Task
  5. Outbound Message
Ver respuesta

Respuesta: C, D, E

A. Invocable FlowIncorrecta. Invocable Flow no es uno de los tipos de acción de los pasos de aprobación aquí.
B. Decision ElementIncorrecta. Decision pertenece a Flow Builder, no a las acciones de aprobación.
C. Email Alert ✓Correcta. Email Alert es una acción disponible en los procesos de aprobación.
D. Task ✓Correcta. Task es una acción disponible en los procesos de aprobación.
E. Outbound Message ✓Correcta. Outbound Message es una acción disponible en los procesos de aprobación.

Por qué: La pregunta evalúa qué tipos de acción están disponibles dentro de un proceso de aprobación. Los procesos de aprobación admiten acciones Email Alert, Task, Field Update y Outbound Message en el envío inicial, la aprobación, el rechazo o la retirada. Decision Element e Invocable Flow son términos de Flow Builder, una confusión frecuente. Aquí las opciones válidas son Email Alert (notificar a los aprobadores), Task (asignar un seguimiento a un usuario) y Outbound Message (enviar datos XML a un endpoint externo sin código). Referencia: Add Automated Actions to a Classic Approval Process | Salesforce Help

14

Un Record-Triggered Flow falla con un error que indica que se superó el número máximo de consultas SOQL. En la ruta de la entrevista del Flow Debugger, el Platform App Builder ve que el mismo elemento Get Records se ejecuta de nuevo por cada registro de la transacción. ¿Qué cambio corregirá el error?

  1. Cambiar el desencadenador del flujo de After-Save a Before-Save.
  2. Mover el elemento Get Records fuera del elemento Loop.
  3. Conectar un Fault Path a un elemento Screen personalizado.
  4. Reemplazar el elemento Loop por un elemento Assignment.
Ver respuesta

Respuesta: B

A. Cambiar el desencadenador del flujo de After-Save a Before-Save.Incorrecta. Cambiar entre before-save y after-save no elimina una consulta dentro de un loop.
B. Mover el elemento Get Records fuera del elemento Loop. ✓Correcta. Consultar una sola vez antes del loop y usar la colección dentro de él.
C. Conectar un Fault Path a un elemento Screen personalizado.Incorrecta. Un Fault Path gestiona el error sin evitarlo, y los Record-Triggered Flows no pueden mostrar pantallas.
D. Reemplazar el elemento Loop por un elemento Assignment.Incorrecta. Un Assignment no puede iterar como un Loop y no elimina la consulta.

Por qué: Se alcanza el límite de SOQL porque Get Records se ejecuta una vez por registro dentro de un Loop en lugar de una sola vez para toda la transacción. Ejecutar un único Get Records antes del loop para obtener todos los datos necesarios, y luego referenciar esa colección dentro del loop, evita una consulta por registro. Esta es la bulkificación estándar y elimina el error de "maximum number of SOQL queries". Referencia: Bulkify Your Flows

Descubre si estás listo para aprobar

Haz el diagnóstico gratis de Platform App Builder: 20 preguntas, sin cuenta. Después desbloquea las 241 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