Object Manager, Fields, and Relationships

The mental model: data, relationship, and experience

When a question says the business needs to store new information, do not automatically answer with a custom field. First decide whether the information is an attribute of an existing record, a new type of record, a relationship between records, or a process variation. That distinction separates Object Manager from record types, page layouts, Flow, and security.

An object answers "what business thing are we tracking". A field answers "what data describes that thing". A relationship answers "how does this thing connect to another thing". A record type answers "which process or values change for the same object". A page layout answers "how is the record presented to the user". If you separate those questions, many scenarios stop feeling ambiguous.

The exam often mixes terms. It may say that a team wants to capture several contracts per account, see maintenance history for an asset, or relate properties to brokers. If the data repeats many times and has its own lifecycle, you probably need a related object. If it is only a simple characteristic of an existing account, a field may be enough. If it changes by process, you may need a record type.

Practical rule: field for attribute, object for entity, relationship for connection, record type for process, layout for presentation.

Object Manager as a configuration hub

Object Manager is the entry point for managing standard and custom objects. From there, you can review Fields & Relationships, page layouts, record types, buttons, links, compact layouts, and other object-level settings. For Administrator, the skill is not only finding the menu, but understanding which configuration belongs to the object and which belongs somewhere else in Setup.

Salesforce describes Object Manager as a central entry point for the org's objects. If you need to create a field on Account, review a relationship on Contact, adjust an Opportunity page layout, or create a custom object, Object Manager is the natural place. If you need to change user permissions, global automation, or sharing rules, you are probably outside the object or in another layer.

In exam questions, Object Manager appears when the scenario mentions custom object, custom field, field type, relationship field, page layout assignment, record type, compact layout, buttons, links, or fields and relationships. The trick is not choosing Object Manager when the real need is data visibility, record access, or automation.

Standard and custom objects

Standard objects are part of Salesforce, such as Account, Contact, Lead, Opportunity, Case, Campaign, and User. Custom objects are created for company-specific or industry-specific information. A custom object can represent properties, internal requests, equipment, courses, assets, special contracts, or any entity that does not fit well into a standard object.

The important decision is not creating objects reflexively. If the data has many records per parent, needs related lists, history, security, its own reports, its own automation, or an independent lifecycle, a custom object can make sense. If the data is one characteristic of an existing record, a field may be enough. If the data represents controlled values, a picklist may be simpler than a full object.

Also think about reporting and security. Creating a new object lets you report on and secure that record set more precisely, but it adds maintenance: permissions, tabs, page layouts, relationships, data import, automation, ownership, and training. On the exam, the best answer is usually the configuration proportional to the problem, not the most elaborate one.

Fields and field types

A field captures one piece of information on an object. Choosing the right type affects validation, reports, automation, search, formulas, and user experience. Text does not behave like number; checkbox does not behave like picklist; date is not datetime; lookup is not a text field even though it visually displays another record.

Picklist works when you want controlled values. Multi-select picklist exists, but it can complicate reports, automation, and filters; do not choose it only because the user wants "several options" without analyzing reporting. Formula calculates a value from other data and usually is not edited manually. Roll-up summary depends on master-detail. Lookup and master-detail create relationships. External ID helps identify records from external systems and is important in loads or integrations.

Field questions usually include clues: "users must select one of approved values" points to picklist; "calculate automatically" points to formula; "track yes/no" points to checkbox; "connect record to another object" points to relationship field; "match records from external system" points to External ID. If the requirement talks about field security, creating the field is not enough: think field-level security.

Lookup vs master-detail

Relationships connect objects. Lookup creates a flexible relationship between records: the child can exist more independently, and ownership, sharing, and deletion are not necessarily tied to the parent as they are in master-detail. Master-detail creates a stronger parent-child relationship: the detail is tightly connected to the master, and this affects ownership, sharing, deletion, roll-up summaries, and detail-record behavior.

If you need a native roll-up summary, master-detail is usually the clue. If the child should not exist without the parent, that also points to master-detail. If you need an optional relationship, independent ownership, or a looser connection between records, lookup is usually better. Salesforce and Trailhead describe master-detail as a one-to-many relationship where one master record can have many detail records and each detail has one master.

The decision should not be made only for reporting. Ask what happens if the parent is deleted, who controls access to the child, whether the child has its own owner, whether roll-ups are needed, and whether the child has an independent life. A contract line item that does not exist without a contract can be master-detail. A case related to a product can be lookup. A broker with many properties in a simple example can be lookup if properties continue to exist as independent records.

Schema Builder

Schema Builder lets you visualize and modify the data model: objects, fields, and relationships. Salesforce says it can be used to view standard and custom objects, inspect lookup and master-detail relationships, and add custom objects, custom fields, and relationships through a visual interface. Trailhead presents it as useful for understanding complex models and explaining how information flows.

On the exam, Schema Builder appears when the main need is seeing the whole model or explaining relationships between objects. If an administrator is unsure how Account, Contact, custom objects, and related records connect, Schema Builder can help. If the question only asks to create a field on Account, Object Manager also works. If it asks to visualize relationships while designing the model, Schema Builder is a strong answer.

Do not confuse Schema Builder with an external diagramming tool. In Salesforce, it shows the real org schema and can create certain elements. Even so, important decisions deserve planning first: draw entities, attributes, relationships, cardinality, ownership, reporting, and security. Creating objects from a visual interface does not replace thinking through the model.

Data model is not security or layout

Object Manager defines structure, but it does not solve everything. Creating a field does not mean everyone should see it. Removing a field from the layout does not mean it is protected. Creating a relationship does not mean the user can see both records. For field security, think field-level security. For record access, think OWD, role hierarchy, sharing rules, and teams. For presentation, think page layouts, Lightning pages, and Dynamic Forms.

This separation appears often in distractors. If the question says you need to store "Renewal Date" on Opportunity, you probably create a field. If it says only managers should see it, also configure field-level security. If it says it should appear in a special section when Stage is Renewal, layout or Dynamic Forms enters. If it says another person should see the opportunity record, that is no longer a field problem: it is sharing.

Also remember that record types are not new objects. If the same object needs different processes, picklists, or layouts, record type may be correct. If you are truly modeling a different entity with relationships, history, and its own reports, it may be an object. The right question is always: am I changing structure, process, security, experience, or automation?

Common mistakes when studying Object Manager

The first mistake is creating custom objects for every list of values. Sometimes a picklist or field is enough. The second mistake is creating text fields for data that should be number, currency, date, checkbox, picklist, or relationship. That seems flexible at first, but it breaks reporting, formulas, validations, and automation.

The third mistake is choosing master-detail only because it "sounds stronger". Master-detail implies real dependency, inherited access, and possible roll-up summaries. If the child record should have independence, lookup may be more correct. The fourth mistake is forgetting External ID when an external system identifies records. Without a reliable identifier, imports and upserts can create duplicates.

The fifth mistake is mixing model and screen. Page layout changes what the user sees on the page; Object Manager and Fields & Relationships change the data structure. The sixth mistake is not reviewing impact: deleting or changing fields can affect reports, flows, formulas, integrations, page layouts, and users.

Quick decision checklist:

Is the information an attribute, entity, relationship, process, or presentation need?
Is there a standard object that already solves the case?
Does the field need controlled values, calculation, date, number, currency, or relationship?
Should the relationship be flexible or dependent on the parent?
What impact will this have on security, reports, automation, and imports?

Official resources and practice

To practice, take a simple process: a company needs to track trainings taken by employees. Decide whether Training is an object, whether Employee should be User, Contact, or a custom object, which fields Training needs, whether Enrollment should be a junction object, and which relationships to use. Then explain which part belongs to Object Manager, which part belongs to page layouts, and which part belongs to permissions.

BlueForce is not affiliated with Salesforce. This guide is original editorial content based on study experience, public objectives, and official resources.