Overview
Object Manager and Lightning App Builder covers the declarative data model and the pages built on it. You need to read the standard object architecture (how Accounts, Contacts, Opportunities, Leads, Cases and Campaigns relate), choose lookup, master-detail or junction designs for custom objects, and use Schema Builder to see or build the model. You also need to create, customize and delete fields safely, and decide how page layouts, Lightning record pages, record types and business processes are assigned to different users.
The section is where requirements from sales, service and data management become structure. A sales process cannot have its own stages without a record type and business process, a dashboard cannot sum child amounts without the right relationship, and a cleanup project can break formulas and roll-ups if fields are deleted carelessly. Automation and reporting questions later assume the object design choices made here.
How it's tested
Expect requirement-driven scenarios: a second business unit needs its own stages, a manager wants a field shown only when a status is set, or an admin wants to retire fields. Questions ask what to create or what will happen. The right answer matches each requirement to the specific feature that controls it: values, layout, page or visibility.
-
Which feature controls this
A requirement about values, fields, sections or actions is given, and you pick record type, business process, page layout, Lightning page or component visibility.
-
Consequence of a change
You are told an admin will delete a field or change a relationship and must predict what breaks or what Salesforce blocks.
-
Pick the relationship
A business rule about ownership, deletion or summarizing child data decides between lookup, master-detail and a junction object.
A company wants renewal opportunities to show only renewal stages and a shorter set of fields. Different available stage values point to a sales process, which reaches users only through a record type. Different fields point to a page layout assigned for that record type and profile. A Lightning page filter alone would change what is displayed but not which stage values can be picked, so it cannot satisfy the requirement.
Objectives 3
Official objectives from the Salesforce outline, in outline order.
2.1 Describe the standard object architecture and relationship model (for example: standard object, parent/child, master detail/lookup/junction relationships, record types, Schema Builder).How core objects connect and how custom relationships behave.
- What it means
- Standard objects come prebuilt with standard relationships, such as Contacts and Opportunities looking up to an Account and Opportunity Contact Roles linking contacts to deals. Custom relationships are lookups (loose, optional), master-detail (tight, inherited ownership and cascade delete) or a junction object with two master-detail fields for many-to-many. Schema Builder shows objects and relationships graphically and can add objects and fields by drag and drop.
- What to understand
- Relationship choice drives security and reporting: a detail record has no owner of its own and inherits sharing from its master, and only master-detail supports roll-up summary fields on custom objects. A standard object cannot be on the detail side of a master-detail relationship, and an object can have at most two master-detail fields.
- How it shows up
- A scenario says child records must disappear with the parent or be summed on it, or that a record must link to many records on another object, and you pick the relationship.
- Common confusion
- Schema Builder is a design and viewing tool, not a data tool; it does not load records or report on them.
2.2 Explain how to create, delete, and customize fields and page layouts on standard and custom objects, and know the implications of deleting fields (roll-up summaries, cross object formulas, picklist dependencies, relationship fields).Changing fields and layouts without breaking dependent features.
- What it means
- Admins add custom fields with the right data type, set field-level security and layout placement while creating them, and edit standard field properties within the limits Salesforce allows. Deleted custom fields go to the Deleted Fields list, where they can be restored with their data for 15 days before permanent removal.
- What to understand
- Salesforce blocks deletion of a field that is still referenced by active metadata such as a formula field, roll-up summary field, or other automation, until you remove the reference. Deleting a controlling field removes its picklist dependency, and deleting a relationship field removes the related list and the ability to report or roll up across that relationship. Changing a field's data type can also truncate or lose existing values.
- How it shows up
- An admin cleans up unused fields and you predict which deletion Salesforce refuses or which downstream formula, roll-up or dependency is affected.
- Common confusion
- Restoring a deleted field brings back data, but not every dependency is rebuilt automatically, so layouts, field-level security and references may need to be set again.
2.3 Given a scenario, determine how to create and assign page layouts, visibility on Lightning page layouts, record types, and business processes for custom and standard objects (quick actions and global actions).Giving each team its own values, fields, page and actions.
- What it means
- Record types let one object offer different picklist values and page layouts to different users. Business processes (sales, support and lead processes) control which Stage or Status values each record type offers. Page layouts are assigned by profile and record type, while Lightning record pages are activated as org default or by app, record type and profile, and can use component visibility filters and Dynamic Forms to show fields and sections conditionally.
- What to understand
- Each requirement maps to one feature: values to a record type and business process, field arrangement to a page layout or Dynamic Forms, overall page design to a Lightning page, and conditional display to visibility rules. Quick actions are object-specific (creating related records with the relationship pre-filled) or global (available anywhere, without a relationship).
- How it shows up
- A new division needs different Stage values, fields and a simpler page, and you identify the combination of sales process, record type, layout assignment and Lightning page activation.
- Common confusion
- Hiding a field with a Lightning page visibility rule is a display choice, not security; the field is still reachable through reports, list views and the API unless field-level security removes it.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Record type
A variant of an object that offers its own set of picklist values, page layout assignment and, for Opportunity, Case, Lead and Solution, its own business process.
- Remember
- Users must be assigned access to a record type through their profile or a permission set before they can create records of it.
- Tested as
- The usual answer when two teams use the same object differently.
- Trap
- Using a record type just to show different fields when one layout with visibility rules would serve every user.
-
Business process
Sales processes, support processes and lead processes list which Stage or Status values a record type can use.
- Remember
- A business process does nothing until a record type uses it, and each record type points to exactly one.
- Tested as
- Tested whenever a division needs its own opportunity stages, case statuses or lead statuses.
- Trap
- Trying to restrict Stage values with a page layout, which controls field placement, not picklist values.
-
Page layout assignment
A matrix that pairs each profile with a page layout for each record type of an object.
- Remember
- Assignment is by profile and record type, so permission sets cannot assign layouts.
- Tested as
- Appears in questions about why one group sees a different layout on the same object.
- Trap
- Expecting a permission set to give a user a different page layout.
-
Lightning record page activation
Lightning App Builder pages can be the org default, the app default, or assigned by app, record type and profile combination.
- Remember
- The most specific assignment wins, so a page set for app plus record type plus profile overrides the org default.
- Tested as
- Scenarios about different page designs for different apps or teams.
- Trap
- Assuming page activation also controls which records users can open, which is the sharing model's job.
-
Component visibility and Dynamic Forms
Visibility filters show or hide components based on record fields, device, user or permission, and Dynamic Forms turns layout fields and sections into individually controlled components.
- Remember
- These are display rules only; field-level security is still what protects data.
- Tested as
- Requirements such as showing a Contract section only when Stage is Closed Won.
- Trap
- Treating a hidden field as secured from users who can still query or report on it.
-
Master-detail relationship
A tight parent-child link where the detail requires a parent, inherits owner and sharing, and is deleted with the parent.
- Remember
- It enables roll-up summary fields on the master, and an object can have at most two master-detail fields.
- Tested as
- Decisions about cascade deletion, inherited security and summarizing child data.
- Trap
- Choosing it when child records need their own owner or must survive the parent's deletion.
-
Lookup relationship
A looser link where the child record keeps its own owner and sharing and the lookup can be optional.
- Remember
- Deletion behavior is configurable on custom lookups, such as clearing the field or blocking parent deletion.
- Tested as
- The default choice when records are related but independent.
- Trap
- Expecting standard roll-up summary fields across a custom lookup.
-
Junction object
A custom object with two master-detail fields that links two objects in a many-to-many relationship.
- Remember
- The first master-detail field created becomes the primary master and sets the junction record's owner and look and feel, and users need read access to both master records to see a junction record.
- Tested as
- Scenarios where a record must relate to many records on another object and vice versa.
- Trap
- Building many-to-many with a single lookup, which only supports one parent per child.
-
Deleted Fields and the 15-day window
Deleted custom fields stay in a Deleted Fields list for 15 days, where they can be restored with their data or erased permanently.
- Remember
- After 15 days the field and its data are gone.
- Tested as
- Questions about recovering from an accidental field deletion.
- Trap
- Assuming field deletion can be undone at any time through the Recycle Bin, which handles records rather than fields.
-
Schema Builder
A drag-and-drop view of objects, fields and relationships that can also create objects and fields.
- Remember
- Good for visualizing a data model before building reports or relationships.
- Tested as
- Appears as the tool to understand or present the data model quickly.
- Trap
- Choosing it to import data or to set page layouts.
-
Object-specific vs. global quick actions
Object-specific actions run from a record and can create related records with the relationship pre-filled; global actions run from anywhere and create records with no relationship to the current page.
- Remember
- Both appear on layouts or in Dynamic Actions, and global actions also appear in the global publisher.
- Tested as
- Tested when users need a fast create or log action from a record or from the header.
- Trap
- Picking a global action when the new record must link back to the record the user is on.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Record type vs. business process vs. page layout vs. Lightning page
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Record type | Variant of an object for a group of users | Controls available picklist values and layout assignment | Creating one when only field placement differs |
| Business process | List of allowed Stage or Status values | Only reaches users through a record type | Expecting it to work without a record type |
| Page layout | Field, section, related list and action arrangement | Assigned by profile and record type | Using it to limit picklist values |
| Lightning record page | Overall page built in Lightning App Builder | Activated by org, app, record type and profile | Thinking it secures fields it hides |
Lookup vs. master-detail vs. junction object (admin view)
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Lookup | Independent related records | Own owner and sharing; configurable delete behavior | Expecting roll-up summaries across it |
| Master-detail | Dependent child records | Cascade delete, inherited sharing, roll-up summaries | Using it when children need their own owner |
| Junction object | Two master-detail fields on one object | Many-to-many; primary master sets owner and look and feel | Forgetting users need access to both master records |
Object-specific action vs. global action
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Object-specific action | Launched from a record of that object | Creates related records with the relationship set | Using a global action and losing the link |
| Global action | Launched from the header or anywhere | Creates records with no automatic relationship | Expecting it to know the current record |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Layout for values
- What candidates pick
- Create a new page layout to give a division different Stage values.
- Why it looks right
- Layouts feel like the way each team gets its own view of a record.
- Why it's wrong
- Page layouts arrange fields; the set of Stage values comes from a sales process attached to a record type.
Clue to watch for The requirement names different picklist values, stages or statuses.
-
Hide equals secure
- What candidates pick
- Hide a salary or discount field with a component visibility filter to keep it from certain users.
- Why it looks right
- The field disappears from the record page as requested.
- Why it's wrong
- Visibility rules control display only; users can still see the field in reports, list views or other pages unless field-level security removes it.
Clue to watch for The scenario uses words like confidential, must not see or restrict access.
-
Just delete the field
- What candidates pick
- Delete an old field immediately as part of a cleanup.
- Why it looks right
- It appears unused on page layouts.
- Why it's wrong
- Formula fields, roll-up summaries, dependencies or automation may reference it, and Salesforce blocks deletion while references remain or breaks dependent features once removed.
Clue to watch for The field is mentioned as feeding a formula, total, dependent picklist or report.
-
Master-detail for independent records
- What candidates pick
- Use master-detail between two custom objects because it supports roll-ups.
- Why it looks right
- Roll-up summaries are attractive and easy.
- Why it's wrong
- Detail records lose their own owner and are deleted with the parent, which breaks requirements for independent ownership or retention.
Clue to watch for The scenario says child records need their own owner or must remain when the parent is deleted.
-
Global action from a record
- What candidates pick
- Add a global New Task action to the Account page so the task is linked to the account.
- Why it looks right
- Global actions show up everywhere and are easy to add.
- Why it's wrong
- A global action does not pre-fill the relationship to the current record; an object-specific action on Account does.
Clue to watch for The new record must automatically relate to the record the user is viewing.
-
Permission set for layouts
- What candidates pick
- Assign a permission set to give a pilot group a different page layout.
- Why it looks right
- Permission sets are the recommended way to vary access.
- Why it's wrong
- Page layout assignment is by profile and record type only; for page-level variation without a new profile, activate a Lightning page by app and record type or use visibility filters on permissions.
Clue to watch for The requirement is a different layout for a subset of users on the same profile.
Answer framework
For any object or page customization scenario, map each requirement to the feature that actually controls it.
- Split the request into parts: different values, different fields, different page design, conditional display, or a new relationship.
- For different Stage or Status values, plan a business process and record type, then grant record type access to the right users.
- For field arrangement, assign page layouts by profile and record type, or use Dynamic Forms with visibility rules on a Lightning page.
- For relationships, choose master-detail only when cascade delete, inherited sharing or roll-ups are required, otherwise a lookup or junction object.
- Before deleting or changing a field, check formulas, roll-ups, dependencies, reports and automation that reference it, and use field-level security where data must be hidden.
Practice question
Want more like this? The Salesforce Admin practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with the standard object model, sketching how Account, Contact, Opportunity, Lead, Case and Campaign connect, then open Schema Builder in a practice org to confirm it. Next, build one custom parent and child object twice, once with a lookup and once with master-detail, and observe ownership, deletion and roll-up behavior.
High-priority concepts are the record type plus business process combination, page layout assignment by profile and record type, and Lightning page activation order. Build a second Opportunity record type with its own sales process and layout, then a Lightning page with a Dynamic Forms section that appears only at a certain stage. Logging in as two users makes the assignment logic concrete.
Commonly underestimated areas are field deletion and quick actions. Try deleting a field used in a formula and one summarized by a roll-up summary, read the messages Salesforce shows, and restore a deleted field from the Deleted Fields list. Afterwards, practice scenario questions that combine several requirements in one sentence and label which feature handles each part before choosing an answer.
FAQ
How much of the exam is Object Manager and Lightning App Builder?
This section is 15% of the Platform Administrator exam, which suggests roughly nine of the 60 scored questions as a planning estimate.
What is the difference between a record type and a page layout?
A record type decides which picklist values and business process a record uses and which layout is assigned. A page layout only arranges fields, sections, related lists and actions. Different values need a record type; different arrangement alone does not.
Do I need to know Dynamic Forms?
The guide asks about visibility on Lightning page layouts, and Dynamic Forms is the standard way to control individual fields and sections on a Lightning record page. Know that it is a display tool and that field-level security still governs data access.
What happens when I delete a custom field?
The field moves to Deleted Fields, where it can be restored with its data for 15 days. Salesforce blocks deleting fields still referenced by formulas, roll-up summaries or other metadata, and deleting a controlling field removes its picklist dependency.
Why can't I give a user a different page layout with a permission set?
Page layout assignment is tied to the profile and record type combination. To vary a page for some users on the same profile, use Lightning page activation by app or record type, or visibility filters based on permissions.
How many hours should I plan for this section?
Roughly 20 to 25 hours is a reasonable editorial estimate, with most of the time spent building record types, layouts and Lightning pages in a practice org.
How does this section connect to reporting?
Report types are built on the object relationships designed here, so a master-detail or lookup decision determines which objects can be reported together and how roll-ups appear in dashboards.
Other CRM & Business Applications certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
You have covered the object model, safe field changes, record types, business processes, layouts and Lightning pages. Check whether you can map each requirement to the feature that controls it under exam timing.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the Salesforce Admin AI tutor Get any concept explained your way