Object Manager, campos y relaciones

El modelo mental: dato, relacion y experiencia

Cuando una pregunta menciona que el negocio necesita guardar nueva informacion, no respondas automaticamente con un campo personalizado. Primero decide si esa informacion es un atributo de un registro existente, un nuevo tipo de registro, una relacion entre registros o una variacion de proceso. Esa diferencia separa Object Manager de record types, page layouts, Flow y seguridad.

Un objeto responde "que cosa del negocio estamos registrando". Un campo responde "que dato describe esa cosa". Una relacion responde "como se conecta esta cosa con otra". Un record type responde "que proceso o valores cambian para el mismo objeto". Un page layout responde "como se presenta el registro al usuario". Si separas esas preguntas, muchos escenarios dejan de parecer ambiguos.

El examen suele mezclar terminos. Puede decir que un equipo quiere capturar varios contratos por cuenta, ver historial de mantenimientos por activo o relacionar inmuebles con brokers. Si el dato se repite muchas veces y tiene su propio ciclo, probablemente necesitas un objeto relacionado. Si solo es una caracteristica simple de una cuenta, tal vez basta un campo. Si cambia por proceso, tal vez necesitas record type.

Regla practica: campo para atributo, objeto para entidad, relacion para conexion, record type para proceso, layout para presentacion.

Object Manager como centro de configuracion

Object Manager es el punto de entrada para administrar objetos estandar y personalizados. Desde ahi puedes revisar Fields & Relationships, page layouts, record types, buttons, links, compact layouts y otras configuraciones propias del objeto. Para Administrator, la habilidad no es solo encontrar el menu, sino entender que configuracion vive en el objeto y que configuracion vive en otra parte de Setup.

Salesforce describe Object Manager como una entrada central para objetos de la org. Si necesitas crear un campo en Account, revisar una relacion en Contact, ajustar un page layout de Opportunity o crear un custom object, Object Manager es el lugar natural. Si necesitas cambiar permisos de usuario, automation global o reglas de sharing, probablemente estas fuera del objeto o en otra capa.

En preguntas de examen, Object Manager aparece cuando el escenario menciona custom object, custom field, field type, relationship field, page layout assignment, record type, compact layout, buttons, links o fields and relationships. El truco esta en no elegir Object Manager si la necesidad real es visibilidad de datos, acceso a registros o automatizacion.

Objetos estandar y personalizados

Los objetos estandar son parte de Salesforce, como Account, Contact, Lead, Opportunity, Case, Campaign y User. Los objetos personalizados se crean para informacion especifica de una empresa o industria. Un custom object puede representar propiedades, solicitudes internas, equipos, cursos, activos, contratos especiales o cualquier entidad que no encaje bien en un objeto estandar.

La decision importante es no crear objetos por reflejo. Si el dato tiene varios registros por padre, necesita related lists, historial, seguridad, reportes propios, automatizacion propia o ciclo de vida independiente, un objeto personalizado puede tener sentido. Si el dato es una sola caracteristica de un registro existente, un campo puede bastar. Si el dato representa valores controlados, tal vez una picklist es mas simple que un objeto completo.

Tambien piensa en reporting y seguridad. Crear un objeto nuevo permite reportar y proteger ese conjunto de registros con mas precision, pero agrega mantenimiento: permisos, tabs, page layouts, relationships, data import, automation, ownership y training. En el examen, la mejor respuesta suele ser la configuracion proporcional al problema, no la mas elaborada.

Campos y tipos de campo

Un campo captura una pieza de informacion dentro de un objeto. Elegir el tipo correcto afecta validacion, reportes, automatizacion, busqueda, formulas y experiencia de usuario. Text no se comporta igual que number; checkbox no se comporta igual que picklist; date no es datetime; lookup no es un campo de texto aunque visualmente muestre otro registro.

Picklist sirve cuando quieres valores controlados. Multi-select picklist existe, pero puede complicar reportes, automatizacion y filtros; no la elijas solo porque el usuario quiere "varias opciones" sin analizar reporting. Formula calcula valor a partir de otros datos y normalmente no se edita manualmente. Roll-up summary depende de master-detail. Lookup y master-detail crean relaciones. External ID ayuda a identificar registros desde sistemas externos y es clave en cargas o integraciones.

Las preguntas de campo suelen incluir pistas: "users must select one of approved values" apunta a picklist; "calculate automatically" apunta a formula; "track yes/no" apunta a checkbox; "connect record to another object" apunta a relationship field; "match records from external system" apunta a External ID. Si el requerimiento habla de seguridad de campo, no basta con crear el campo: debes pensar en field-level security.

Lookup vs master-detail

Las relaciones conectan objetos. Lookup crea una relacion flexible entre registros: el hijo puede existir de forma mas independiente, y la propiedad, sharing y eliminacion no dependen necesariamente del padre como en master-detail. Master-detail crea una relacion mas fuerte de padre a hijo: el detalle esta muy ligado al master, y esto afecta propiedad, sharing, eliminacion, roll-up summaries y comportamiento del registro detalle.

Si necesitas roll-up summary nativo, master-detail suele ser la pista. Si el hijo no debe existir sin el padre, tambien apunta a master-detail. Si necesitas una relacion opcional, independencia de propietario o conectar registros de manera mas suelta, lookup suele ser mejor. Salesforce y Trailhead describen master-detail como relacion de uno a muchos en la que un registro master puede tener muchos detalles y cada detalle tiene un master.

La decision no debe tomarse solo por reporting. Pregunta que pasa si se borra el padre, quien controla acceso al hijo, si el hijo tiene owner propio, si se necesitan roll-ups y si el registro hijo tiene vida independiente. Un contrato line item que no existe sin contrato puede ser master-detail. Un caso relacionado con un producto puede ser lookup. Un broker con muchas propiedades en un ejemplo simple puede ser lookup si las propiedades siguen existiendo como registros independientes.

Schema Builder

Schema Builder permite visualizar y modificar el modelo de datos: objetos, campos y relaciones. Salesforce indica que se puede usar para ver objetos estandar y personalizados, observar lookup y master-detail relationships, y agregar custom objects, custom fields y relaciones mediante una interfaz visual. Trailhead lo presenta como una herramienta util para entender modelos complejos y explicar como fluye la informacion.

En el examen, Schema Builder aparece cuando la necesidad principal es ver el modelo completo o explicar relaciones entre objetos. Si un administrador no esta seguro de como se conectan Account, Contact, custom objects y related records, Schema Builder puede ayudar. Si la pregunta solo pide crear un campo en Account, Object Manager tambien sirve. Si pide visualizar relaciones para disenar el modelo, Schema Builder es una respuesta fuerte.

No confundas Schema Builder con herramienta de diagramacion externa. En Salesforce, permite ver el schema real de la org y tambien crear ciertos elementos. Aun asi, para decisiones importantes conviene planear antes: dibujar entidades, atributos, relaciones, cardinalidad, ownership, reporting y seguridad. Crear objetos desde una interfaz visual no reemplaza pensar el modelo.

Modelo de datos no es seguridad ni layout

Object Manager define estructura, pero no resuelve todo. Crear un campo no significa que todos deban verlo. Quitar un campo del layout no significa que este protegido. Crear una relacion no significa que el usuario pueda ver ambos registros. Para seguridad de campo, piensa field-level security. Para acceso a registros, piensa OWD, role hierarchy, sharing rules y teams. Para presentacion, piensa page layouts, Lightning pages y Dynamic Forms.

Esta separacion aparece mucho en distractores. Si la pregunta dice que se necesita guardar "Fecha de renovacion" en Opportunity, probablemente creas un campo. Si dice que solo managers deben verlo, tambien configuras field-level security. Si dice que debe aparecer en una seccion especial cuando Stage es Renewal, entra layout o Dynamic Forms. Si dice que otra persona debe ver el registro de oportunidad, eso ya no es campo: es sharing.

Tambien recuerda que record types no son objetos nuevos. Si el mismo objeto necesita procesos, picklists o layouts distintos, record type puede ser correcto. Si de verdad estas modelando una entidad diferente con relaciones, historial y reportes propios, puede ser objeto. La pregunta correcta siempre es: estoy cambiando estructura, proceso, seguridad, experiencia o automatizacion?

Errores comunes al estudiar Object Manager

El primer error es crear custom objects para cualquier lista de valores. A veces una picklist o un campo basta. El segundo error es crear campos de texto para datos que deberian ser numero, moneda, fecha, checkbox, picklist o relacion. Eso parece flexible al inicio, pero rompe reportes, formulas, validaciones y automatizacion.

El tercer error es elegir master-detail solo porque "suena mas fuerte". Master-detail implica dependencia real, herencia de acceso y posibilidad de roll-up summary. Si el registro hijo debe tener independencia, lookup puede ser mas correcto. El cuarto error es olvidar External ID cuando un sistema externo identifica registros. Sin identificador confiable, importaciones y upserts pueden crear duplicados.

El quinto error es mezclar modelo y pantalla. Page layout cambia lo que el usuario ve en la pagina; Object Manager y Fields & Relationships cambian la estructura de datos. El sexto error es no revisar impacto: borrar o cambiar campos puede afectar reportes, flows, formulas, integraciones, page layouts y usuarios.

Checklist de decision rapida:

La informacion es atributo, entidad, relacion, proceso o presentacion?
Existe un objeto estandar que ya resuelve el caso?
El campo necesita valores controlados, calculo, fecha, numero, moneda o relacion?
La relacion debe ser flexible o dependiente del padre?
Que impacto tendra en seguridad, reportes, automatizacion e importaciones?

Recursos oficiales y practica

Para practicar, toma un proceso simple: una empresa necesita registrar entrenamientos tomados por empleados. Decide si Training es objeto, si Employee debe ser User, Contact o custom object, que campos necesita Training, si Enrollment debe ser un objeto intermedio y que relaciones usar. Despues explica que parte corresponde a Object Manager, que parte a page layouts y que parte a permisos.

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