Praxis Academy
Inicio › Platform App Builder › Data Modeling and Management

Preguntas de práctica Platform App Builder: Data Modeling and Management

Data Modeling and Management vale 20% del examen Salesforce Certified Platform App Builder. Cubre relaciones, tipos de campo, external IDs y herramientas de datos. Resuelve estas 21 preguntas gratis y abre cada respuesta para ver por qué cada opción es correcta o incorrecta.

01

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.
  2. Agregar en Building__c un campo de relación Master-Detail que apunte a Inspection__c.
  3. Agregar en Inspection__c un campo de relación Lookup obligatorio que apunte a Building__c.
  4. Agregar en Inspection__c un campo de relación Master-Detail que apunte a Building__c.
Ver respuesta

Respuesta: D

A. 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.
B. 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.
C. 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.
D. Agregar en Inspection__c un campo de relación Master-Detail que apunte a Building__c. ✓Correcta. Un campo Master-Detail en el hijo Inspection__c elimina las inspecciones junto con su edificio y hace que hereden su uso compartido.

Por qué: Ambos requisitos, la eliminación en cascada y el uso compartido heredado, son comportamientos integrados de las relaciones Master-Detail. El campo de relación siempre se crea en el objeto detalle (hijo). Inspection es el lado 'muchos', así que el campo Master-Detail va en Inspection__c y apunta a Building__c. Así, al eliminar un edificio se eliminan sus inspecciones, y las inspecciones siguen el acceso del edificio. Referencia: Object Relationships Overview

02

Un Platform App Builder crea una relación Master-Detail con Galaxy__c como padre y Star__c como hijo. ¿Qué implica esto para los usuarios que quieren generar informes de Galaxy__c junto con Star__c?

  1. Se debe crear un nuevo Report Type personalizado para Star__c usando campos de búsqueda de Galaxy__c.
  2. Se crea automáticamente un Report Type de Star__c que incluye Galaxy__c como campo.
  3. Se crea automáticamente un Report Type Galaxy__c with Star__c.
  4. Se debe crear un nuevo Report Type personalizado para Galaxy__c with Star__c.
Ver respuesta

Respuesta: C

A. Se debe crear un nuevo Report Type personalizado para Star__c usando campos de búsqueda de Galaxy__c.Incorrecta. No se requiere trabajo manual; el Report Type de padre con hijos se genera automáticamente.
B. Se crea automáticamente un Report Type de Star__c que incluye Galaxy__c como campo.Incorrecta. El Report Type generado tiene al padre como objeto principal (Galaxy with Star), no al hijo.
C. Se crea automáticamente un Report Type Galaxy__c with Star__c. ✓Correcta. Salesforce crea automáticamente un Report Type 'Galaxy__c with Star__c' cuando ambos objetos permiten informes.
D. Se debe crear un nuevo Report Type personalizado para Galaxy__c with Star__c.Incorrecta. El Report Type se crea automáticamente, así que no se necesita un Report Type personalizado.

Por qué: Crear una relación Master-Detail tiene un efecto secundario en los informes. Cuando ambos objetos tienen habilitados los informes, Salesforce genera automáticamente un Report Type estándar 'padre con hijos', en este caso 'Galaxy__c with Star__c'. Los usuarios pueden generar informes de galaxias con sus estrellas relacionadas sin configuración adicional. Referencia: Criteria to Generate a Standard Report Type

03

Una empresa de servicios informáticos tiene un objeto personalizado de planes de servicio, y cada plan de servicio debe vincularse con exactamente un contacto. El gerente de soporte descubrió que, cuando se vincula el contacto equivocado, los representantes no pueden cambiarlo. El Platform App Builder confirmó que los usuarios tienen el acceso de campo adecuado y que no existen Validation Rules en los planes de servicio. ¿Cuál es la causa?

  1. La casilla Allow reparenting (Child records can be reparented to other parent records after they are created) está seleccionada.
  2. Está elegido el botón de opción Read Only (Allows users with at least Read access to the Master record to create, edit, or delete related Detail records).
  3. Está elegido el botón de opción Read/Write (Allows users with at least Read/Write access to the Master record to create, edit, or delete related Detail records).
  4. La casilla Allow reparenting (Child records can be reparented to other parent records after they are created) está desmarcada.
Ver respuesta

Respuesta: D

A. La casilla Allow reparenting (Child records can be reparented to other parent records after they are created) está seleccionada.Incorrecta. Si se permitiera cambiar el padre, los representantes podrían cambiar el contacto.
B. Está elegido el botón de opción Read Only (Allows users with at least Read access to the Master record to create, edit, or delete related Detail records).Incorrecta. Este ajuste de uso compartido controla quién puede crear, editar o eliminar registros detalle, no si el padre puede cambiar.
C. Está elegido el botón de opción Read/Write (Allows users with at least Read/Write access to the Master record to create, edit, or delete related Detail records).Incorrecta. Este ajuste de uso compartido controla quién puede crear, editar o eliminar registros detalle, no si el padre puede cambiar.
D. La casilla Allow reparenting (Child records can be reparented to other parent records after they are created) está desmarcada. ✓Correcta. Con Allow reparenting desmarcada, el registro maestro (el contacto) no se puede cambiar una vez que existe el registro detalle.

Por qué: El acceso a campos y las Validation Rules quedan descartados, así que el bloqueo proviene de la propia relación. 'Allow reparenting' en una relación Master-Detail determina si el padre de un registro detalle se puede cambiar después de su creación. Cuando está desmarcada, el Contact se puede establecer una vez y nunca cambiarse, que es exactamente lo que viven los representantes. Referencia: Considerations for Object Relationships

04

Helix Labs exporta datos de oportunidades a Excel y necesita el ID de registro de 18 caracteres para que no se confundan dos registros. ¿Qué fórmula debe usar el Platform App Builder para el nuevo campo?

  1. ISNUMBER(Id)
  2. CASESAFEID(Id)
  3. TEXT(Id)
  4. VALUE(Id)
Ver respuesta

Respuesta: B

A. ISNUMBER(Id)Incorrecta. ISNUMBER() solo devuelve verdadero o falso y no transforma un Id.
B. CASESAFEID(Id) ✓Correcta. CASESAFEID() genera la versión de 18 caracteres del Id del registro que no distingue mayúsculas y minúsculas.
C. TEXT(Id)Incorrecta. TEXT() no agrega los tres caracteres de verificación adicionales.
D. VALUE(Id)Incorrecta. VALUE() convierte texto en número y generaría un error con un Id.

Por qué: Salesforce muestra IDs de 15 caracteres que distinguen mayúsculas y minúsculas. Excel no distingue entre mayúsculas y minúsculas, por lo que dos IDs que solo difieren en el uso de mayúsculas pueden parecer el mismo valor después de exportarlos. CASESAFEID() convierte el ID de 15 caracteres en su versión de 18 caracteres que no distingue mayúsculas y minúsculas, la cual sigue siendo única en cualquier herramienta. Referencia: CASESAFEID

05

Helix Labs quiere almacenar el contenido de un white paper de producto en un campo del objeto Product. El contenido incluye tablas, listas e imágenes. ¿Qué tipo de campo debe elegir el Platform App Builder para que se muestre correctamente?

  1. Text Area
  2. Text Area (Long)
  3. Text Area (Rich)
  4. Text Area (Encrypted)
Ver respuesta

Respuesta: C

A. Text AreaIncorrecta. Un Text Area almacena una cantidad pequeña de texto plano sin formato ni imágenes.
B. Text Area (Long)Incorrecta. Un Long Text Area permite más caracteres, pero sigue almacenando solo texto plano.
C. Text Area (Rich) ✓Correcta. Un Rich Text Area admite formato, listas, tablas e imágenes mediante su barra de herramientas.
D. Text Area (Encrypted)Incorrecta. Un campo de texto cifrado enmascara valores sensibles y solo admite texto plano.

Por qué: Solo un campo Rich Text Area maneja contenido con formato, como texto en negritas, listas, tablas e imágenes incrustadas. Incluye una barra de herramientas de edición para dar formato e insertar imágenes, por lo que el white paper conserva su estructura. Referencia: Custom Field Types

06

Helix Labs descubrió un segundo sol y ahora quiere que la relación entre Sun__c y Planet__c sea Lookup en lugar de Master-Detail. Antes del cambio, ¿qué impacto en los informes debe tener en cuenta el Platform App Builder?

  1. Los informes existentes basados en el Report Type Sun__c with Planet__c creado por Salesforce se eliminarán.
  2. Los campos Roll-Up Summary existentes permanecerán en Sun__c y seguirán disponibles en informes, pero dejarán de actualizarse.
  3. Los campos Roll-Up Summary existentes se eliminarán de Sun__c y de todos los informes que los usan.
  4. Los informes existentes basados en el Report Type Sun__c with Planet__c creado por Salesforce podrían quedar inutilizables, pero no se eliminarán.
Ver respuesta

Respuesta: C

A. Los informes existentes basados en el Report Type Sun__c with Planet__c creado por Salesforce se eliminarán.Incorrecta. El Report Type y sus informes permanecen; solo desaparecen los campos Roll-Up Summary.
B. Los campos Roll-Up Summary existentes permanecerán en Sun__c y seguirán disponibles en informes, pero dejarán de actualizarse.Incorrecta. Los campos Roll-Up Summary no pueden existir con un Lookup, así que no permanecen en el objeto.
C. Los campos Roll-Up Summary existentes se eliminarán de Sun__c y de todos los informes que los usan. ✓Correcta. Los Roll-Up Summary requieren Master-Detail, así que pasar a Lookup los elimina del objeto y de los informes. (En la práctica, Salesforce exige eliminarlos antes de permitir la conversión).
D. Los informes existentes basados en el Report Type Sun__c with Planet__c creado por Salesforce podrían quedar inutilizables, pero no se eliminarán.Incorrecta. El Report Type y los informes siguen siendo utilizables; lo que se ve afectado son los campos Roll-Up Summary.

Por qué: Los campos Roll-Up Summary dependen de una relación Master-Detail; un Lookup no puede admitirlos. Por lo tanto, convertir la relación implica perder los campos Roll-Up Summary y, como los campos dejan de existir, también desaparecen de los informes que los incluían. El Report Type y los informes en sí permanecen. Referencia: Roll-Up Summary Field

07

Helix Labs tiene una picklist Country en tres objetos personalizados distintos. Los valores deben mantenerse idénticos en los tres objetos. ¿Qué funcionalidad debe usar el Platform App Builder?

  1. State and Country Picklist
  2. Next Best Action
  3. Field Update
  4. Global Picklist Value Set
Ver respuesta

Respuesta: D

A. State and Country PicklistIncorrecta. Las State and Country Picklists se aplican a los campos de dirección estándar, no a picklists personalizadas.
B. Next Best ActionIncorrecta. Next Best Action sugiere acciones a los usuarios; no administra valores de picklist.
C. Field UpdateIncorrecta. Un Field Update cambia datos dentro de una automatización; no mantiene alineadas las listas de valores.
D. Global Picklist Value Set ✓Correcta. Un Global Value Set ofrece una sola lista de valores compartida por picklists de varios objetos.

Por qué: Un Global Value Set es una lista reutilizable de valores de picklist que se define una sola vez, de forma independiente de cualquier objeto. Los campos picklist de varios objetos pueden basarse en ella, y al editar el conjunto se actualizan todos los campos que lo usan. Referencia: Create a Global Picklist Value Set

08

Helix Labs usará un objeto personalizado para registrar los detalles de instalación después de que se compra un contenedor. Los representantes de ventas deben poder ver todas las instalaciones vinculadas a sus oportunidades. ¿Qué relación debe tener el nuevo objeto con Opportunity?

  1. Lookup
  2. Muchos a muchos
  3. Master-Detail
  4. Jerárquica
Ver respuesta

Respuesta: A

A. Lookup ✓Correcta. Un Lookup del objeto de instalación a Opportunity muestra las instalaciones relacionadas en la oportunidad sin las características de Master-Detail.
B. Muchos a muchosIncorrecta. Muchos a muchos requiere un objeto de unión, que el escenario no necesita.
C. Master-DetailIncorrecta. Master-Detail implica eliminación en cascada y uso compartido heredado, que no se requieren.
D. JerárquicaIncorrecta. Las relaciones jerárquicas solo están disponibles en el objeto User.

Por qué: Un Lookup del objeto de instalación a Opportunity vincula los registros y pone a disposición una lista relacionada de instalaciones en la oportunidad. El escenario no requiere eliminación en cascada, Roll-Ups ni uso compartido heredado, así que Master-Detail agregaría complejidad innecesaria. Referencia: Object Relationships Overview

09

Helix Labs quiere que la página de detalle de Account muestre cuántas oportunidades Closed Won tienen una fecha de cierre dentro del último año. ¿Qué debe usar el Platform App Builder?

  1. Campo Roll-Up Summary
  2. Validation Rule
  3. Campo de fórmula
  4. Activity Timeline
Ver respuesta

Respuesta: A

A. Campo Roll-Up Summary ✓Correcta. Un Roll-Up COUNT en Account filtrado a Closed Won muestra el número en la página de la cuenta. Los filtros de Roll-Up no admiten fechas relativas como 'el último año', por lo que normalmente se usa un campo auxiliar (por ejemplo, una casilla que un flujo mantiene actualizada) para el periodo.
B. Validation RuleIncorrecta. Las Validation Rules impiden guardar registros; no pueden mostrar conteos.
C. Campo de fórmulaIncorrecta. Un campo de fórmula no puede contar registros hijos relacionados.
D. Activity TimelineIncorrecta. El Activity Timeline lista actividades, no conteos de oportunidades.

Por qué: Un campo Roll-Up Summary con COUNT y criterios de filtro es la forma declarativa de mostrar en el Account padre un conteo agregado de las oportunidades hijas. Se recalcula automáticamente cuando cambian las oportunidades y aparece en la página de Account sin código. Referencia: Create a Roll-Up Summary Field

10

Brightline Energy configura el Organization-Wide Default de Account como Private. Marketing es propietario de algunas cuentas, pero también necesita ver las cuentas propiedad de ventas. Ventas y marketing están en ramas totalmente separadas de la Role Hierarchy. ¿Qué funcionalidad permite que marketing vea las cuentas propiedad de ventas?

  1. Sharing Rules
  2. Grupos públicos
  3. Alias
  4. Reglas de asignación
Ver respuesta

Respuesta: A

A. Sharing Rules ✓Correcta. Una Sharing Rule puede extender las cuentas de ventas a marketing incluso entre ramas separadas de la jerarquía.
B. Grupos públicosIncorrecta. Un grupo público puede ser el destino de una Sharing Rule, pero un grupo por sí solo no otorga acceso.
C. AliasIncorrecta. Los alias son nombres cortos de visualización de usuarios y no tienen relación con el uso compartido.
D. Reglas de asignaciónIncorrecta. Las reglas de asignación enrutan Leads y Cases; no comparten cuentas.

Por qué: Con un OWD Private, los usuarios solo ven sus propios registros más los que les otorgan la jerarquía, las Sharing Rules o el uso compartido manual. Como los dos equipos están en ramas diferentes, la jerarquía no le otorga nada a marketing. Una Sharing Rule puede abrir las cuentas de ventas a marketing con base en roles, grupos públicos o criterios. Referencia: Sharing Rules | Salesforce Help

11

Brightline Energy tiene un objeto personalizado de plan de servicio, y cada plan debe pertenecer exactamente a un contacto. El gerente de soporte descubrió que, cuando un plan se vincula al contacto equivocado, los representantes no pueden cambiarlo. El app builder verificó que los usuarios tienen el acceso adecuado a los campos y que no hay Validation Rules en los planes de servicio. ¿Cuál es la causa probable?

  1. Está seleccionado el botón de opción Read Only, Allows users with at least Read access to the Master record to create, edit, or delete related Detail records.
  2. La casilla Allow reparenting, Child records can be reparented to other parent records after they are created, está desmarcada.
  3. Está seleccionado el botón de opción Read/Write, Allows users with at least Read/Write access to the Master record to create, edit, or delete related Detail records.
  4. La casilla Allow reparenting, Child records can be reparented to other parent records after they are created, está marcada.
Ver respuesta

Respuesta: B

A. Está seleccionado el botón de opción Read Only, Allows users with at least Read access to the Master record to create, edit, or delete related Detail records.Incorrecta. Esta opción de uso compartido controla quién puede crear, editar o eliminar registros de detalle, no el cambio de padre.
B. La casilla Allow reparenting, Child records can be reparented to other parent records after they are created, está desmarcada. ✓Correcta. Cuando Allow reparenting está desmarcada, el contacto de un plan de servicio no puede cambiarse después de su creación.
C. Está seleccionado el botón de opción Read/Write, Allows users with at least Read/Write access to the Master record to create, edit, or delete related Detail records.Incorrecta. Esta opción de uso compartido controla quién puede crear, editar o eliminar registros de detalle, no el cambio de padre.
D. La casilla Allow reparenting, Child records can be reparented to other parent records after they are created, está marcada.Incorrecta. Si se permitiera el cambio de padre, los representantes podrían cambiar el contacto.

Por qué: El plan de servicio está ligado a su contacto mediante una relación Master-Detail. Descartados el acceso a campos y las validaciones, la causa restante es la configuración 'Allow reparenting' de la relación, que está desmarcada de forma predeterminada. Mientras esté desmarcada, el maestro (contacto) de un registro de detalle existente (plan de servicio) no puede cambiarse. Referencia: Considerations for Object Relationships | Salesforce Help

12

Una empresa de energía necesita que cada Account muestre cuántos registros de Opportunity tiene relacionados. ¿Qué se debe usar?

  1. Campo de fórmula
  2. Una solución de AppExchange
  3. Campo Lookup
  4. Campo Roll-Up Summary
Ver respuesta

Respuesta: D

A. Campo de fórmulaIncorrecta. Un campo de fórmula no puede contar registros hijos relacionados.
B. Una solución de AppExchangeIncorrecta. No se necesita un producto de AppExchange; es una funcionalidad nativa.
C. Campo LookupIncorrecta. Un campo Lookup define una relación, pero no cuenta nada.
D. Campo Roll-Up Summary ✓Correcta. Un campo Roll-Up Summary en Account con el tipo COUNT totaliza las oportunidades relacionadas.

Por qué: El objetivo es un solo número en el Account: el conteo de sus Opportunities hijas. Account y Opportunity tienen una relación especial que se comporta como Master-Detail, por lo que se puede crear un campo Roll-Up Summary en Account. Con el tipo de resumen COUNT, contabiliza automáticamente los registros de Opportunity relacionados, sin código ni productos de terceros.

13

Una empresa de servicios públicos quiere mejorar la gestión de casos. Los casos no deben poder regresar a un estado anterior y ciertos campos deben ser obligatorios cuando se cumplen condiciones específicas del caso. ¿Qué debe implementar el app builder?

  1. Configurar Validation Rules con texto de ayuda.
  2. Crear campos de lista de selección dependiente y marcarlos como obligatorios.
  3. Usar un proceso de aprobación para verificar los criterios de los campos.
  4. Marcar los campos como obligatorios en el Page Layout.
Ver respuesta

Respuesta: A

A. Configurar Validation Rules con texto de ayuda. ✓Correcta. Las Validation Rules pueden bloquear cambios de estado hacia atrás y exigir campos bajo condiciones específicas, con un mensaje de error claro.
B. Crear campos de lista de selección dependiente y marcarlos como obligatorios.Incorrecta. Las listas de selección dependientes filtran valores, pero no pueden impedir que se revierta un estado.
C. Usar un proceso de aprobación para verificar los criterios de los campos.Incorrecta. Los procesos de aprobación enrutan registros para su autorización; no aplican reglas de datos al guardar.
D. Marcar los campos como obligatorios en el Page Layout.Incorrecta. Los campos obligatorios en el Page Layout aplican en todas las situaciones, no solo cuando se cumplen ciertos criterios.

Por qué: Ambos requisitos son verificaciones condicionales al guardar. Las Validation Rules pueden usar PRIORVALUE() o ISCHANGED() para impedir que un estado retroceda, y lógica como AND(ISPICKVAL(Status, "Closed"), ISBLANK(Resolution_Notes__c)) para exigir campos solo en ciertas situaciones. Sus mensajes de error indican a los usuarios cómo corregir el registro. Un campo obligatorio en el Page Layout aplica siempre y no puede expresar ninguna de las dos condiciones.

14

Un app builder está agregando un campo nuevo a un objeto personalizado y no quiere que aparezca en los Report Types personalizados que ya existen. ¿Qué se debe hacer en la configuración del campo personalizado?

  1. Quitar el campo nuevo de todos los Page Layouts.
  2. Eliminar su visibilidad para todos los perfiles de informes.
  3. Dar a todos los perfiles de informes acceso de solo lectura.
  4. Desmarcar la opción de agregar automáticamente al Report Type personalizado.
Ver respuesta

Respuesta: D

A. Quitar el campo nuevo de todos los Page Layouts.Incorrecta. Los Page Layouts no determinan qué campos están en los Report Types.
B. Eliminar su visibilidad para todos los perfiles de informes.Incorrecta. Ocultar el campo lo elimina por completo para los usuarios, lo cual no es lo que se pidió.
C. Dar a todos los perfiles de informes acceso de solo lectura.Incorrecta. Un campo de solo lectura puede seguir apareciendo en los Report Types.
D. Desmarcar la opción de agregar automáticamente al Report Type personalizado. ✓Correcta. Desmarcar 'Auto Add to Custom Report Type' durante la creación del campo lo mantiene fuera de los Report Types personalizados existentes.

Por qué: El asistente de creación de campos tiene su propia casilla 'Auto Add to Custom Report Type'. Si se deja seleccionada, el campo nuevo se agrega automáticamente a los Report Types personalizados existentes; al desmarcarla, el campo queda fuera. Los Page Layouts y la visibilidad del campo son configuraciones independientes y no controlan las columnas de los Report Types.

15

Una empresa de biotecnología tiene un nuevo objeto personalizado Invoice con un campo Invoice Number. Antes de la puesta en producción, las facturas se migrarán desde un sistema externo y deben conservar sus Invoice Numbers existentes. Después de la migración, cada Invoice creada en Salesforce debe tener un Invoice Number único. ¿Cómo debe configurar el Platform App Builder el campo Invoice Number?

  1. Usar un campo AutoNumber y migrar las facturas en orden de Invoice Number.
  2. Usar un campo Text y marcarlo como External ID único.
  3. Usar un campo Text para el Invoice Number original y un campo AutoNumber para el Invoice Number de Salesforce.
  4. Usar un campo Text y cambiarlo a AutoNumber después de la migración.
Ver respuesta

Respuesta: B

A. Usar un campo AutoNumber y migrar las facturas en orden de Invoice Number.Incorrecta. Los campos AutoNumber no se pueden cargar con los números de factura existentes.
B. Usar un campo Text y marcarlo como External ID único. ✓Correcta. Un campo Text External ID único conserva los números originales, admite upserts y garantiza la unicidad de ahí en adelante.
C. Usar un campo Text para el Invoice Number original y un campo AutoNumber para el Invoice Number de Salesforce.Incorrecta. Dos campos de número de factura generan confusión y no garantizan la unicidad de los números originales.
D. Usar un campo Text y cambiarlo a AutoNumber después de la migración.Incorrecta. Convertirlo a AutoNumber reemplaza los valores migrados con números nuevos.

Por qué: Un campo Text puede almacenar los números de factura originales tal como están, algo que un campo AutoNumber no acepta durante una carga. Marcarlo como External ID permite hacer coincidencias y upserts contra el sistema de origen, y marcarlo como Unique hace que Salesforce rechace números duplicados en cada guardado posterior.

16

Una empresa de instalación solar necesita relacionar el objeto estándar Contact con un objeto personalizado Solar Project. Un contacto puede participar en muchos proyectos solares y un proyecto solar puede involucrar a muchos contactos. ¿Cómo debe diseñar el app builder el modelo de datos?

  1. Dos relaciones Master-Detail en un nuevo objeto personalizado
  2. Una relación Master-Detail en Contact y otra relación Master-Detail en Solar Project
  3. Dos relaciones Lookup en un nuevo objeto personalizado
  4. Una relación Lookup en Contact y otra relación Lookup en Solar Project
Ver respuesta

Respuesta: A

A. Dos relaciones Master-Detail en un nuevo objeto personalizado ✓Correcta. Un objeto de unión con un Master-Detail a Contact y otro a Solar Project es el modelo estándar de muchos a muchos.
B. Una relación Master-Detail en Contact y otra relación Master-Detail en Solar ProjectIncorrecta. Un campo de relación colocado directamente en Contact o en Solar Project apunta a un solo registro del otro lado.
C. Dos relaciones Lookup en un nuevo objeto personalizadoIncorrecta. Dos Lookup pueden vincular los objetos, pero carecen de la eliminación en cascada y la herencia de uso compartido que ofrece un verdadero objeto de unión.
D. Una relación Lookup en Contact y otra relación Lookup en Solar ProjectIncorrecta. Los Lookup en cada objeto solo crean vínculos de uno a muchos, no de muchos a muchos.

Por qué: Se trata de una relación de muchos a muchos: cualquiera de los lados puede tener muchos registros relacionados en el otro. Un solo campo de relación en cualquiera de los objetos solo puede apuntar a un registro, por lo que no puede modelar esto. La solución estándar es un objeto de unión (junction object) en medio con dos relaciones Master-Detail, una a Contact y otra a Solar Project, de modo que cualquier contacto pueda vincularse a cualquier cantidad de proyectos y viceversa.

17

Una empresa de educación astronómica quiere que el campo Type del objeto padre Galaxy se muestre en el registro hijo Star. El app builder obtiene el error 'Picklist values are only supported in certain functions.' ¿Qué fórmula debe usar el app builder?

  1. TEXT(Galaxy__r.Type__c)
  2. ISPICKVAL(Galaxy__r.Type__c)
  3. VALUE(Galaxy__r.Type__c)
  4. String(Galaxy__r.Type__c)
Ver respuesta

Respuesta: A

A. TEXT(Galaxy__r.Type__c) ✓Correcta. TEXT() convierte el valor de la lista de selección del padre en texto que la fórmula puede devolver.
B. ISPICKVAL(Galaxy__r.Type__c)Incorrecta. ISPICKVAL() compara una lista de selección con un valor específico y devuelve verdadero o falso.
C. VALUE(Galaxy__r.Type__c)Incorrecta. VALUE() convierte texto en número; no convierte listas de selección.
D. String(Galaxy__r.Type__c)Incorrecta. String() no es una función de fórmula de Salesforce.

Por qué: Un campo de lista de selección no se puede usar tal cual en la mayoría de las funciones de fórmula; primero debe convertirse a texto. Envolver la referencia entre objetos en TEXT() convierte el valor de Type seleccionado en el padre en una cadena que la fórmula puede mostrar en Star.

18

Un distribuidor tiene cinco años de historial de ventas y quiere registrar la fecha de la primera compra de cada cliente. ¿Cómo debe usar el app builder un Roll-Up Summary para esto?

  1. Agregar un nuevo campo de fecha llamado First Order Date y luego crear un Roll-Up Summary de tipo MIN para actualizarlo.
  2. Agregar un nuevo campo Roll-Up Summary llamado First Order Date que use el tipo MIN sobre Close Date de Opportunity, filtrado por isWon = TRUE.
  3. Agregar un nuevo campo de fecha llamado First Order Date y luego llenarlo con un Roll-Up Summary sobre Close Date de Opportunity.
  4. Agregar un nuevo campo Roll-Up Summary llamado First Order Date que use el tipo SUM sobre Close Date de Opportunity.
Ver respuesta

Respuesta: B

A. Agregar un nuevo campo de fecha llamado First Order Date y luego crear un Roll-Up Summary de tipo MIN para actualizarlo.Incorrecta. El campo Roll-Up Summary contiene el valor por sí mismo; no se necesita un campo de fecha aparte.
B. Agregar un nuevo campo Roll-Up Summary llamado First Order Date que use el tipo MIN sobre Close Date de Opportunity, filtrado por isWon = TRUE. ✓Correcta. MIN sobre Close Date, filtrado por IsWon = TRUE, devuelve la fecha de la oportunidad ganada más antigua.
C. Agregar un nuevo campo de fecha llamado First Order Date y luego llenarlo con un Roll-Up Summary sobre Close Date de Opportunity.Incorrecta. Un Roll-Up Summary no 'establece' un campo de fecha aparte.
D. Agregar un nuevo campo Roll-Up Summary llamado First Order Date que use el tipo SUM sobre Close Date de Opportunity.Incorrecta. SUM no está disponible para campos de fecha.

Por qué: La fecha del primer pedido es la Close Date más antigua entre las oportunidades ganadas de la cuenta. MIN devuelve el valor más pequeño entre los registros hijos, mientras que SUM no se puede usar con fechas. El propio campo Roll-Up Summary almacena el resultado, y un filtro IsWon = TRUE lo limita a los negocios que se convirtieron en ventas reales.

19

Un app builder quiere un campo de fórmula en Account que use datos de los Contacts relacionados, pero la relación no aparece en el editor de fórmulas. ¿Qué limitación de las fórmulas explica esto?

  1. La fórmula supera los 5,000 caracteres.
  2. Contact y Account NO tienen una relación Master-Detail.
  3. No se puede hacer referencia a registros hijos.
  4. El objeto Account alcanzó su límite de campos de fórmula.
Ver respuesta

Respuesta: C

A. La fórmula supera los 5,000 caracteres.Incorrecta. La longitud de la fórmula no tiene nada que ver con que falte la relación.
B. Contact y Account NO tienen una relación Master-Detail.Incorrecta. El tipo de relación no es la causa; las fórmulas no pueden llegar a registros hijos a través de ninguna relación.
C. No se puede hacer referencia a registros hijos. ✓Correcta. Las fórmulas entre objetos solo pueden hacer referencia a registros padre, nunca a registros hijos como los contactos de una cuenta.
D. El objeto Account alcanzó su límite de campos de fórmula.Incorrecta. Alcanzar el límite de campos impediría crear el campo, no ocultaría la relación.

Por qué: Las fórmulas entre objetos solo van hacia arriba, de un hijo a su padre. Un Account puede tener muchos Contacts con valores distintos, por lo que no existe un único valor hijo que se pueda traer a una fórmula. Por eso la relación con Contact no se ofrece en el editor.

20

En un distribuidor de equipos solares, un objeto personalizado Galaxy__c está vinculado a un objeto personalizado Star__c mediante una relación Lookup. El app builder quiere un campo Roll-Up Summary que muestre cuántos registros de Star__c pertenecen a cada registro de Galaxy__c. ¿Qué implica la configuración actual para lograr este objetivo?

  1. Un campo de fórmula en el objeto Galaxy__c puede entregar el resultado del resumen.
  2. Antes de crear cualquier campo Roll-Up Summary, el Lookup debe cambiarse a una relación Master-Detail.
  3. Un campo de fórmula en el objeto Star__c puede entregar el resultado del resumen.
  4. Crear un campo Roll-Up Summary en Galaxy__c cuyo filtro de campo incluya todos los registros relacionados de Star__c.
Ver respuesta

Respuesta: B

A. Un campo de fórmula en el objeto Galaxy__c puede entregar el resultado del resumen.Incorrecta. Una fórmula en el registro padre no puede contar sus registros hijos.
B. Antes de crear cualquier campo Roll-Up Summary, el Lookup debe cambiarse a una relación Master-Detail. ✓Correcta. Los Roll-Up Summary requieren Master-Detail, por lo que primero hay que convertir el Lookup; cada registro de Star__c debe hacer referencia a un Galaxy__c.
C. Un campo de fórmula en el objeto Star__c puede entregar el resultado del resumen.Incorrecta. Una fórmula en el registro hijo no puede contar sus registros hermanos.
D. Crear un campo Roll-Up Summary en Galaxy__c cuyo filtro de campo incluya todos los registros relacionados de Star__c.Incorrecta. Los filtros no ayudan; los campos Roll-Up Summary simplemente no están disponibles en una relación Lookup.

Por qué: Los campos Roll-Up Summary solo existen en el lado maestro de una relación Master-Detail. Como Galaxy__c y Star__c están unidos por un Lookup, no se puede crear ningún Roll-Up Summary, sin importar la fórmula o el filtro que se use. Convertir el Lookup a Master-Detail (lo que exige que cada registro de Star__c tenga un valor en Galaxy__c) habilita un resumen COUNT en Galaxy__c.

21

Un gerente de servicio pide al Platform App Builder que codifique por colores los casos abiertos según su antigüedad: - Los casos recién creados muestran un círculo verde. - Los casos con un día de antigüedad muestran un círculo amarillo. - Los casos con tres días de antigüedad muestran un círculo rojo. ¿Qué herramienta debe usar el app builder?

  1. Botón personalizado
  2. Lightning web component
  3. Campo de fórmula
  4. Quick action
Ver respuesta

Respuesta: C

A. Botón personalizadoIncorrecta. Un botón requiere que el usuario haga clic y no muestra un indicador automático.
B. Lightning web componentIncorrecta. Un LWC personalizado implica escribir código cuando un campo de fórmula resuelve esto de forma declarativa.
C. Campo de fórmula ✓Correcta. Una fórmula con IMAGE() y lógica IF sobre la antigüedad del caso muestra automáticamente el círculo del color correcto.
D. Quick actionIncorrecta. Una quick action depende de la interacción del usuario y no muestra un indicador.

Por qué: Un campo de fórmula puede calcular la antigüedad del caso (por ejemplo TODAY() - DATEVALUE(CreatedDate)) y usar lógica IF anidada con la función IMAGE() para devolver un círculo verde, amarillo o rojo. Es declarativo, no requiere código y se recalcula automáticamente.

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