Praxis Academy

Examen de práctica Salesforce Certified Platform App Builder

El examen real tiene 60 preguntas, dura 105 minutos y se aprueba con 63%. Empieza con un diagnóstico gratis de 20 preguntas, sin cuenta.

Haz el diagnóstico gratis

Secciones del examen y su peso

Preguntas de muestra

Una empresa de ciencias de la vida guarda en un objeto personalizado las tarjetas de desempeño de sus representantes de ventas. Cada tarjeta debe ser visible solo para el representante, su gerente y los ejecutivos por encima de ese gerente. Además, los representantes no deben poder ver los campos de comentarios ejecutivos en su propia tarjeta. ¿Qué debe hacer el Platform App Builder para cumplir ambos requisitos?

  1. Establecer el modelo de uso compartido en Private y otorgar acceso a los registros mediante la jerarquía; controlar la visibilidad de los campos con Record Types y field-level security.
    Incorrecta. Los Record Types determinan los valores de picklist y la asignación de layouts; no protegen los datos de los campos.
  2. Establecer el modelo de uso compartido en Private y otorgar acceso a los registros mediante custom settings; controlar la visibilidad de los campos con Page Layouts y field-level security.
    Incorrecta. Los custom settings almacenan datos de configuración y no pueden compartir registros.
  3. Establecer el modelo de uso compartido en Private y otorgar acceso a los registros mediante la jerarquía; controlar la visibilidad de los campos con field-level security. (Respuesta)
    Correcta. Un OWD Private más el acceso por jerarquía cubre a gerentes y ejecutivos, y field-level security mantiene los comentarios ejecutivos fuera del alcance de los representantes.
  4. Establecer el modelo de uso compartido en Private y otorgar acceso a los registros mediante custom settings; controlar la visibilidad de los campos con Record Types y Page Layouts.
    Incorrecta. Los custom settings no comparten registros, y los Page Layouts solo ocultan campos visualmente; los datos siguen accesibles mediante informes o la API.

Una administradora de inmuebles tiene dos objetos personalizados sin relación, Inspection__c y Building__c. Se registran unas tres inspecciones por edificio cada año. Al eliminar un edificio se deben eliminar automáticamente sus inspecciones, y cada inspección debe tener el mismo uso compartido y acceso que su edificio. ¿Cómo debe relacionar los objetos el Platform App Builder?

  1. Agregar en Building__c un campo de relación Lookup obligatorio que apunte a Inspection__c.
    Incorrecta. El campo está en el objeto equivocado, y los Lookups no eliminan en cascada ni transmiten el uso compartido del padre.
  2. Agregar en Building__c un campo de relación Master-Detail que apunte a Inspection__c.
    Incorrecta. Esto convertiría a Building en hijo de Inspection, lo contrario de lo que se necesita.
  3. Agregar en Inspection__c un campo de relación Lookup obligatorio que apunte a Building__c.
    Incorrecta. El objeto es el correcto, pero un Lookup no elimina en cascada ni hereda el uso compartido del padre.
  4. Agregar en Inspection__c un campo de relación Master-Detail que apunte a Building__c. (Respuesta)
    Correcta. Un campo Master-Detail en el hijo Inspection__c elimina las inspecciones junto con su edificio y hace que hereden su uso compartido.

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 (Respuesta)
    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.
  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
    Incorrecta. La ruta programada retrasa la actualización una hora y es menos eficiente que una actualización before-save.
  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
    Incorrecta. Los procesos de aprobación envían registros a aprobación; no están pensados para registrar un campo en cada cambio de etapa.
  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
    Incorrecta. Un flujo lanzado por botón depende de que el usuario recuerde hacer clic, así que no es automático.

Las preguntas son originales y siguen la guía oficial del examen. Praxis Academy no está afiliada a Salesforce, Inc.