Praxis Academy
Inicio › Platform App Builder › Salesforce Fundamentals

Preguntas de práctica Platform App Builder: Salesforce Fundamentals

Salesforce Fundamentals vale 18% del examen Salesforce Certified Platform App Builder. Cubre modelo de seguridad, configuración del org y AppExchange. Resuelve estas 5 preguntas gratis y abre cada respuesta para ver por qué cada opción es correcta o incorrecta.

01

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.
  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.
  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.
  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.
Ver respuesta

Respuesta: C

A. 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.
B. 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.
C. 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. ✓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.
D. 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.

Por qué: Se aplican dos restricciones a la vez: el registro debe seguir la cadena de reporte hacia arriba y uno de sus campos debe permanecer oculto para el representante. Un Org-Wide Default Private parte de cero acceso más allá del propietario, y 'Grant Access Using Hierarchies' abre automáticamente cada registro a los usuarios que están por encima del propietario en la Role Hierarchy. Field-level security es la función que realmente oculta un campo a un Profile o Permission Set, sin importar el layout, los informes o la API. Referencia: Organization-Wide Sharing Defaults

02

Un campo personalizado de Account contiene información financiera del cliente, y solo el equipo de finanzas puede acceder a él. Para casos especiales, el negocio quiere que un agente de servicio al cliente con el Profile Customer Service tenga acceso de solo lectura a ese campo. ¿Cuál es la forma recomendada de darle acceso a este agente?

  1. Editar la field-level security del campo personalizado en Setup para otorgar al agente acceso de solo lectura.
  2. Crear un Permission Set que otorgue field-level security de solo lectura sobre el campo y asignarlo al agente.
  3. Crear un nuevo Profile que otorgue field-level security de solo lectura sobre el campo y asignarlo al agente.
  4. Cambiar el Profile Customer Service actual del agente para otorgar field-level security de solo lectura sobre el campo.
Ver respuesta

Respuesta: B

A. Editar la field-level security del campo personalizado en Setup para otorgar al agente acceso de solo lectura.Incorrecta. Configurar la accesibilidad del campo en Setup funciona por Profile, así que afectaría a todos los usuarios con ese Profile.
B. Crear un Permission Set que otorgue field-level security de solo lectura sobre el campo y asignarlo al agente. ✓Correcta. Un Permission Set con field-level security de solo lectura, asignado solo a este agente, otorga acceso únicamente a ese usuario.
C. Crear un nuevo Profile que otorgue field-level security de solo lectura sobre el campo y asignarlo al agente.Incorrecta. Crear un Profile completo para un solo campo agrega una carga innecesaria frente a un Permission Set.
D. Cambiar el Profile Customer Service actual del agente para otorgar field-level security de solo lectura sobre el campo.Incorrecta. Editar el Profile Customer Service expondría el campo a todos los agentes que lo usan.

Por qué: Solo una persona necesita el campo, así que el cambio no debe llegar a los demás agentes con el mismo Profile. Un Permission Set puede dar field-level security de solo lectura sobre ese único campo y asignarse solo a ese agente. El Profile base no cambia, lo que sigue la práctica de mínimo privilegio de manejar las excepciones con Permission Sets. Referencia: Field Permissions

03

Una empresa da seguimiento a proyectos internos en un objeto personalizado Projects, organizado por departamento, con un Org-Wide Default Private. Los empleados deben ver todos los registros de proyectos de su propio departamento y, cuando alguien se transfiere a otro departamento, debe perder el acceso a los proyectos del departamento anterior. ¿Qué enfoque cumple estos requisitos?

  1. Crear un Sharing Rule basado en criterios sobre el departamento del Project que comparta registros con Public Groups.
  2. Crear un Sharing Rule basado en criterios sobre el departamento del Project que comparta registros con Permission Sets.
  3. Crear un Sharing Rule basado en criterios sobre el departamento del Project que comparta registros con Profiles.
  4. Crear un Sharing Rule basado en criterios sobre el departamento del Project que comparta registros con Account Teams.
Ver respuesta

Respuesta: A

A. Crear un Sharing Rule basado en criterios sobre el departamento del Project que comparta registros con Public Groups. ✓Correcta. Compartir por departamento con un Public Group del departamento significa que el acceso cambia simplemente al mover usuarios entre grupos.
B. Crear un Sharing Rule basado en criterios sobre el departamento del Project que comparta registros con Permission Sets.Incorrecta. Los Sharing Rules no pueden compartir registros con Permission Sets.
C. Crear un Sharing Rule basado en criterios sobre el departamento del Project que comparta registros con Profiles.Incorrecta. Los Sharing Rules no pueden compartir registros con Profiles.
D. Crear un Sharing Rule basado en criterios sobre el departamento del Project que comparta registros con Account Teams.Incorrecta. Los Account Teams pertenecen a Accounts y no aplican a un objeto personalizado Project.

Por qué: El acceso debe seguir el valor de departamento del registro y ajustarse limpiamente cuando las personas cambian de departamento. Un Sharing Rule basado en criterios abre todos los Projects con un valor de departamento dado a un destino, y los Sharing Rules pueden apuntar a Public Groups, roles o territorios. Un Public Group por departamento representa la membresía actual, así que mover a un usuario de un grupo a otro cambia su acceso de inmediato. Referencia: Create Criteria-Based Sharing Rules

04

Los representantes de ventas de campo trabajan en Salesforce desde sus teléfonos. Necesitan una forma rápida de agregar nuevos contactos y volver más tarde para completar los demás datos. ¿Qué solución móvil debe recomendar el Platform App Builder para crear estos contactos?

  1. Usar Path con valores predefinidos.
  2. Crear una acción global que cree Contacts.
  3. Agregar un Compact Layout a Contacts.
  4. Reordenar el menú móvil para que Contacts aparezca primero.
Ver respuesta

Respuesta: B

A. Usar Path con valores predefinidos.Incorrecta. Path guía a los usuarios por las etapas de un registro existente; no agiliza la creación de registros.
B. Crear una acción global que cree Contacts. ✓Correcta. Una acción global Create Contact con solo unos cuantos campos permite a los representantes agregar contactos rápidamente desde cualquier parte de la app.
C. Agregar un Compact Layout a Contacts.Incorrecta. Los Compact Layouts definen los campos que se muestran en el panel destacado del registro; no crean registros.
D. Reordenar el menú móvil para que Contacts aparezca primero.Incorrecta. Cambiar el orden del menú no hace más rápida la creación de contactos.

Por qué: La necesidad es capturar registros rápidamente en el móvil y agregar el resto de los datos después. Una acción global puede crear un Contact desde cualquier parte de la app móvil de Salesforce y limitarse a unos cuantos campos clave, así que los representantes guardan en segundos y completan el registro más tarde. Referencia: Create Global Quick Actions

05

Una empresa necesita enviar periódicamente un envío masivo de correo a unos 7,000 contactos almacenados en Salesforce, pero la función nativa de correo masivo limita cuántos correos pueden salir por día. ¿Qué debe hacer el Platform App Builder?

  1. Pedir a Salesforce que aumente el máximo diario de correos.
  2. Investigar y evaluar productos de AppExchange para enviar correos masivos.
  3. Exportar los Contacts a un archivo CSV y enviar los correos desde un cliente de correo.
  4. Desarrollar código Apex y un Lightning web component que envíen los correos a diario.
Ver respuesta

Respuesta: B

A. Pedir a Salesforce que aumente el máximo diario de correos.Incorrecta. El límite diario de correo masivo es fijo y no se aumenta a petición.
B. Investigar y evaluar productos de AppExchange para enviar correos masivos. ✓Correcta. Los productos de correo y marketing de AppExchange están diseñados para envíos recurrentes de alto volumen.
C. Exportar los Contacts a un archivo CSV y enviar los correos desde un cliente de correo.Incorrecta. Enviar desde un cliente de correo pierde el seguimiento en Salesforce y agrega riesgos de cumplimiento.
D. Desarrollar código Apex y un Lightning web component que envíen los correos a diario.Incorrecta. El código personalizado sigue sujeto a los límites de correo y agrega mantenimiento.

Por qué: El límite diario de correo masivo es un límite fijo de la plataforma, así que la solución debe venir de una herramienta diseñada para envíos masivos. Para correo frecuente de alto volumen, la recomendación estándar es un producto dedicado de correo o marketing (por ejemplo Marketing Cloud, Account Engagement u otra app de AppExchange) que gestione el envío masivo, la entregabilidad y el cumplimiento. Así se evita escribir código personalizado para rodear un límite. Referencia: Salesforce Mass Email Limits

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