Record types, page layouts y Lightning pages.

El modelo mental: proceso, datos y experiencia

Cuando una pregunta dice que usuarios necesitan "ver una pagina diferente", no respondas de inmediato con Lightning App Builder. Primero decide que significa diferente. Tal vez necesitan valores de picklist distintos porque siguen procesos de negocio distintos. Tal vez necesitan campos, botones o related lists diferentes. Tal vez necesitan componentes en otra posicion, visibilidad condicional o una experiencia distinta por app, perfil, record type o form factor.

Salesforce reparte esas responsabilidades entre varias herramientas. Record types separan procesos y valores disponibles. Page layouts controlan muchos aspectos del detalle tradicional del registro. Lightning App Builder organiza componentes y activa paginas por contexto. Dynamic Forms permite controlar campos de forma mas granular dentro de Lightning App Builder. Compact layouts controlan los campos clave del highlights panel y otras vistas compactas.

Record types

Record types permiten ofrecer diferentes procesos de negocio, valores de picklist y asignaciones de pagina para un mismo objeto. Son utiles cuando el mismo objeto representa escenarios con comportamiento distinto. Por ejemplo, oportunidades nuevas y renovaciones pueden tener etapas diferentes; casos tecnicos y casos de facturacion pueden tener status distintos; cuentas de partner y cuentas de cliente pueden requerir layouts diferentes.

El record type no es simplemente una etiqueta bonita. Afecta que valores puede seleccionar el usuario, que proceso aplica y que page layout puede ver segun su perfil. Por eso no conviene crear record types para cualquier variacion menor. Si solo necesitas esconder un campo para ciertos usuarios, tal vez field-level security, Dynamic Forms o page layout sea suficiente. Si necesitas separar procesos y picklists, record type gana sentido.

En preguntas de examen, busca palabras como different sales processes, different support processes, different picklist values, different page layouts by process o same object used for multiple business processes. Esas frases suelen apuntar a record types. Si la pregunta solo pide mostrar un componente adicional para usuarios de una app, probablemente mira hacia Lightning App Builder.

Page layouts

Page layouts controlan muchos elementos que aparecen en una pagina de registro: campos dentro del Record Detail tradicional, secciones, related lists, botones, links y acciones. Tambien participan en la asignacion por perfil y record type. Si una organizacion usa record types, la combinacion de perfil y record type determina que page layout ve el usuario.

Page layout no es seguridad absoluta. Quitar un campo de un layout no necesariamente impide acceso al campo en todos los lugares. Para seguridad de campo, debes pensar en field-level security. Page layout puede hacer campos requeridos o read-only en la interfaz, pero si la pregunta habla de impedir acceso al dato de forma consistente, field-level security puede ser mas correcto.

En el examen, page layout suele ser candidato cuando el escenario menciona fields on the page, related lists, buttons, actions, sections, assignment by profile and record type o inline edit behavior. Si una pregunta dice que dos perfiles deben ver diferentes related lists en el mismo objeto, page layout puede ser suficiente. Si dice que deben ver componentes Lightning distintos por app o dispositivo, mira Lightning pages.

Lightning pages y Lightning App Builder

Lightning pages son paginas compuestas por componentes en regiones. Lightning App Builder permite cambiar estructura, tabs, componentes estandar, componentes personalizados y visibilidad de componentes. Tambien permite activar paginas para combinaciones de app, record type, perfil y form factor, segun el tipo de pagina y configuracion disponible.

La gran diferencia con page layout es que Lightning App Builder controla la experiencia de Lightning: donde aparecen componentes, que secciones existen, que componentes se muestran para cierto contexto y como se organiza la pagina. Page layout todavia puede controlar campos si la pagina usa el componente Record Detail, ademas de acciones y related lists tradicionales.

Si la pregunta habla de rearrange components, show a component only when a field has a value, assign a page to an app, optimize phone versus desktop, add a custom Lightning component o create a custom record page, Lightning App Builder es candidato fuerte. Si habla de cambiar columnas de una related list tradicional o asignar layout por perfil y record type, page layout sigue siendo relevante.

Dynamic Forms y visibilidad condicional

Dynamic Forms permite colocar campos y secciones como componentes individuales dentro de Lightning App Builder, en lugar de depender de un bloque completo de Record Detail. Esto permite visibilidad condicional mas granular: mostrar un campo cuando otro campo tiene cierto valor, separar secciones por contexto o reducir ruido para usuarios que no necesitan ver todo.

Dynamic Forms no reemplaza todos los conceptos. Field-level security sigue controlando seguridad del dato. Page layouts pueden seguir afectando acciones, related lists y comportamiento en partes de la experiencia. Record types siguen separando procesos y valores de picklist. Dynamic Forms es especialmente util cuando la pregunta pide mostrar u ocultar campos en la pagina Lightning segun condiciones, sin crear muchos layouts duplicados.

La trampa es usar Dynamic Forms para resolver proceso de negocio. Si el problema es que dos tipos de oportunidad necesitan etapas distintas, no basta con ocultar campos. Eso apunta a record type y sales process. Si el problema es que un campo solo debe aparecer cuando Stage es Closed Lost, Dynamic Forms o component visibility puede ser la mejor respuesta.

Compact layouts, highlights y acciones

Compact layouts determinan los campos clave que aparecen en el highlights panel y en otras vistas compactas, como vistas de lookup o tarjetas. Son importantes porque ayudan al usuario a reconocer un registro rapido sin abrir todos los detalles. En Lightning Experience, los primeros campos del compact layout tienen visibilidad especial en el encabezado del registro.

No confundas compact layout con page layout. Si la pregunta pide controlar los campos principales que se ven arriba en el record page o en una tarjeta compacta, compact layout es candidato. Si pide reorganizar todos los campos del detalle, piensa page layout o Dynamic Forms. Si pide mostrar acciones principales en el encabezado, page layout y Dynamic Actions pueden entrar segun el contexto.

Las acciones tambien generan preguntas. Object-specific actions aprovechan contexto del registro; global actions son mas amplias. Dynamic Actions permiten controlar acciones en Lightning de forma mas flexible cuando la configuracion lo soporta. Si la pregunta pide que una accion aparezca solo bajo ciertas condiciones en Lightning, no respondas automaticamente page layout; revisa si Dynamic Actions encaja mejor.

Errores comunes al estudiar configuracion de paginas

El primer error es crear record types para todo. Si solo quieres ocultar o mostrar campos, probablemente no necesitas separar procesos. Record types tienen costo de mantenimiento porque afectan picklists, asignaciones, automatizaciones, reportes y experiencia de usuario. Usalos cuando existe una diferencia real de proceso o valores.

El segundo error es confundir layout con seguridad. Un campo fuera del layout no equivale necesariamente a un campo protegido. Si una pregunta dice que ciertos usuarios nunca deben ver salary, margin o datos sensibles, field-level security suele pesar mas. El tercer error es olvidar que Lightning pages y page layouts pueden trabajar juntos: la pagina Lightning puede contener un Record Detail que aun toma campos del page layout.

El cuarto error es leer "different page" sin identificar la causa. Si cambia el objeto y sus relaciones, piensa Object Manager. Si cambian valores por proceso, piensa record type. Si cambia el detalle tradicional, piensa page layout. Si cambian componentes, visibilidad, app o dispositivo, piensa Lightning App Builder. Si cambia la cabecera compacta, piensa compact layout.

Recursos oficiales y practica

Para practicar este tema, toma un objeto como Opportunity y disena dos procesos: venta nueva y renovacion. Define que picklists cambian, que record types necesitas, que layouts aplican por perfil, que componentes van en la Lightning page y que campos merecen Dynamic Forms. Despues practica preguntas subrayando palabras como process, picklist, layout, component, visibility, profile y record type.

• Trailhead: Customize Record Page Components and Fields
• Salesforce Help: Lightning App Builder or Page Layout Editor
• Salesforce Help: Assign Page Layouts to Profiles or Record Types
• Trailhead: Customize the User Interface
• Guia completa de Salesforce Platform Administrator
• Practicar preguntas de Platform Administrator

BlueForce no esta afiliado a Salesforce. Esta guia es contenido editorial original basado en experiencia de estudio, objetivos publicos y recursos oficiales.