Salesforce Object Manager is the central administration hub where every Salesforce admin manages the data model – custom fields, page layouts, record types, validation rules, relationships between objects, and the field-level security that controls who sees what. If you are new to Salesforce administration or preparing for the Salesforce Administrator certification, understanding Object Manager is foundational: it is the interface through which Salesforce’s famous flexibility is realised without writing code. This guide covers every section of Object Manager in detail, with practical examples for each configuration area.
That kind of planning saves cleanup work later.
When the object structure is thought through early, the rest of the CRM is easier to keep organized.
The best overview is the one that makes the data model feel manageable.
A clear explanation should help the reader understand both the flexibility and the responsibility involved.
That means the guide should connect configuration choices to practical outcomes.
For many admins, Object Manager is where the CRM starts to become truly tailored to the team.
It should also show how structure decisions made here influence reporting, usability, and data quality later.
A good guide should explain why object-level control matters and how it affects the rest of the platform.
That makes it one of the most important admin areas to understand.
Salesforce Object Manager is useful because it gives admins a central place to control custom fields, layouts, and parts of the data model. It helps turn Salesforce from a generic CRM into a system that matches the business more closely.
That kind of planning saves cleanup work later.
When the object structure is thought through early, the rest of the CRM is easier to keep organized.
The best overview is the one that makes the data model feel manageable.
A clear explanation should help the reader understand both the flexibility and the responsibility involved.
That means the guide should connect configuration choices to practical outcomes.
For many admins, Object Manager is where the CRM starts to become truly tailored to the team.
It should also show how structure decisions made here influence reporting, usability, and data quality later.
A good guide should explain why object-level control matters and how it affects the rest of the platform.
That makes it one of the most important admin areas to understand.
Salesforce Object Manager is useful because it gives admins a central place to control custom fields, layouts, and parts of the data model. It helps turn Salesforce from a generic CRM into a system that matches the business more closely.
Accessing Salesforce Object Manager
Object Manager is accessed via Setup (gear icon in the top navigation bar) ? Object Manager. The Object Manager home screen lists all Salesforce objects available in your org – both standard Salesforce objects (Account, Contact, Opportunity, Lead, Case, Task, Event, and more) and any custom objects that have been created in your org. The list is searchable by object label or API name.
Each object in Object Manager has a set of sub-sections accessible from the left sidebar when the object is selected. These sections are identical for both standard and custom objects, though some options are limited on certain standard objects.
Object Manager Sections Explained
1. Details
The Details section shows the object’s configuration metadata: label (singular and plural), API name, description, and key feature toggles. For custom objects, you can enable or disable:
- Allow Reports: Whether records of this object can be included in Salesforce Reports – disable for lookup-table style objects that don’t need reporting
- Allow Activities: Whether Tasks and Events can be related to this object – enable for any object where users need to log calls and meetings
- Track Field History: Enable field history tracking (up to 20 fields per object) – stores a time-stamped audit trail of field value changes, viewable in the Field History related list on the record
- Allow Search: Whether records of this object appear in global search results
- Allow Sharing: Enables the Sharing button on records – allows record owners to manually share individual records with users or groups
2. Fields and Relationships
The most frequently used Object Manager section – where all fields on the object are listed and new fields are created. The field list shows: Field Label, API Name, Data Type, and whether the field is part of the standard field set or custom. Key operations:
- New Field: Create a custom field – choose from 20 data types including Text, Number, Currency, Date, Picklist, Lookup Relationship, Formula, Roll-Up Summary, and more
- Set Field-Level Security: After creating a field, set which profiles can see and edit it – fields can be visible to all users, visible but read-only for certain profiles, or hidden entirely from certain profiles
- Add to Page Layouts: After field-level security is set, choose which page layouts the field appears on
- Edit: Modify an existing field’s label, help text, default value, or picklist values
- Delete: Permanently remove a custom field and all its data – irreversible without data restoration, so requires confirmation
Relationship Fields Explained
The two relationship field types are critical for building connected data models:
- Lookup Relationship: Links a record on this object to a record on another object. Loose coupling – if the parent record is deleted, the lookup field on the child is cleared but the child record remains. An Opportunity has a lookup to Account – deleting an Account does not delete its Opportunities, it clears the Account lookup field on those Opportunities
- Master-Detail Relationship: Tight coupling – the child record cannot exist without its parent. Deleting the parent deletes all children. Enables Roll-Up Summary fields on the parent. The Opportunity Line Item (Product) is in a master-detail relationship with its Opportunity – deleting the Opportunity deletes all its line items
3. Page Layouts
Page Layouts define which fields, related lists, buttons, and custom links appear on the record detail page, and in what order. A single object can have multiple page layouts assigned to different user profiles or record types – sales reps might see a streamlined layout with key selling fields, while managers see additional pipeline and forecast fields.
The Page Layout editor is drag-and-drop: drag fields from the palette to sections on the layout, drag related lists into the Related Lists section at the bottom. Key options:
- Required fields: Fields can be marked required on the page layout (in addition to or instead of being required at the field definition level)
- Read-only fields: Fields can be set as read-only on a specific layout – users can see the value but cannot edit it (field-level security is a separate control that operates at the profile level)
- Sections: Organise the page into labelled sections – “Deal Information”, “Customer Details”, “Internal Notes” – displayed as collapsed or expanded by default
- Related Lists: Choose which child object related lists appear at the bottom of the page and in what order, and which columns display in each related list
- Buttons: Add or remove standard and custom buttons from the page header button bar
4. Record Types
Record Types enable different subsets of the same object to behave differently – different page layouts, different picklist value subsets, and different business processes. Every Record Type is assigned to a Business Process (for Opportunity, Lead, and Case) or simply defines layout and picklist variants for other objects.
Common Record Type use cases:
- Opportunity Record Types: “New Business”, “Renewal”, “Expansion” – each showing relevant fields and picklist values for that deal type
- Case Record Types: “Technical Support”, “Billing Inquiry”, “Feature Request” – routing each to a different support queue and showing type-appropriate fields
- Account Record Types: “Prospect”, “Customer”, “Partner” – showing relationship-appropriate fields for each account category
5. Validation Rules
Validation Rules prevent records from being saved when defined conditions are met – enforcing data quality at the point of entry. Each Validation Rule has:
- Rule Name: Internal identifier
- Error Condition Formula: A formula that evaluates to TRUE when the data is invalid – the record save is blocked when this formula returns TRUE
- Error Message: The message displayed to the user explaining why the save was blocked
- Error Location: Whether the error message appears at the top of the page or adjacent to a specific field
6. Triggers
The Triggers section lists any Apex triggers associated with the object – these are programmatic (code-based) automation that fires on record operations. Admins without developer skills can view existing triggers here but cannot create or modify them without Apex development knowledge. Triggers are created by developers for complex automation logic that exceeds what Flow Builder can handle declaratively.
7. Search Layouts
Search Layouts control which fields appear in search results, lookup dialogs, and list views for the object:
- Search Results Layout: Fields shown when this object appears in global search results
- Lookup Dialogs Layout: Fields shown when a user searches for records of this type via a lookup field on another object
- List View Layout: The default columns available in list views for this object
8. Buttons, Links, and Actions
Custom Buttons, Custom Links, and Quick Actions are created in this section:
- Custom Buttons: URL-based or JavaScript buttons that appear on the record page – used for launching external URLs with record field values as parameters, or triggering simple JavaScript actions
- Custom Links: Hyperlinks that can be embedded in page layouts – useful for linking to external systems with CRM record data included in the URL
- Quick Actions: Create / Update / Log a Call actions that appear in the Highlights Panel on the record and in the mobile app – configured to create new records pre-populated with related record data, or to update specific fields on the current record via a focused modal dialog
9. Compact Layouts
Compact Layouts define the fields displayed in the record’s Highlights Panel (the summary bar at the top of a record page) and on the Salesforce Mobile App record card view. A good compact layout shows the 4-6 most important fields for immediate context – typically: record name, owner, key status field, and one or two key dates or metrics. Compact Layouts are assigned per Record Type, allowing different highlight fields for different record categories.
10. Field Sets
Field Sets are named groupings of fields that can be referenced programmatically or in managed packages – less commonly used by admins directly, but relevant for companies using AppExchange products that expose Field Set configuration for customisation.
11. Limits
The Limits section shows current object-level limits in the org: number of custom fields (maximum 500 per object on Enterprise), number of validation rules (maximum 100 per object), number of page layouts, and other object-level configuration counts. Monitor this section when building complex custom objects to ensure limits are not approaching.
Creating a Custom Object from Scratch
To create a new custom object in Object Manager: Setup ? Object Manager ? Create ? Custom Object. Required configuration at creation:
- Label: Singular and plural display name (e.g., “Project” / “Projects”)
- Object Name: API name – auto-generated from label, suffixed with
__cto identify custom objects (e.g.,Project__c) - Record Name: The primary identifier field – either an auto-generated number (e.g., “PRJ-0001”) or a text field that the user enters
- Feature toggles: Reports, Activities, Field History Tracking, Search, etc.
- Deployment Status: “Deployed” makes the object available to users; “In Development” hides it while being built
Object Manager vs Schema Builder
Schema Builder (Setup ? Schema Builder) is an alternative visual interface that shows the data model as a connected entity-relationship diagram – useful for understanding how objects relate to each other in a complex org. Admins can create new custom fields and objects from Schema Builder, but Object Manager is more comprehensive for managing all aspects of each object. Schema Builder is most valuable as a documentation and exploration tool rather than a primary administration interface.
Object Manager Best Practices: Building a Clean Salesforce Data Model
What is Salesforce Object Manager and how do you access it?
Salesforce Object Manager is the unified administration interface for managing all Salesforce objects (both standard and custom) in Lightning Experience. It replaced the individual object setup pages that existed in Classic. Access Object Manager through Setup > Object Manager (available in the left sidebar of Setup in Lightning). Within Object Manager, you can manage: Fields and Relationships (create, edit, delete custom fields), Page Layouts (control field arrangement on record views), Record Types (define different record categories with different layouts and picklist values), Validation Rules (enforce data quality), Triggers (Apex code associated with the object), and object-level settings like enabling history tracking, search settings, and sharing settings. Object Manager consolidates all object configuration into one place, replacing what previously required navigating multiple separate Setup sections.
How do you create a custom field in Salesforce?
To create a custom field in Salesforce: (1) Go to Setup > Object Manager and select the object you want to add a field to. (2) Click Fields and Relationships, then New. (3) Select the Data Type for your field (Text, Number, Date, Picklist, Formula, Lookup, etc.) and click Next. (4) Configure the field properties: Label (what users see), Field Name (API name used in code and formulas), Length (for text fields), Default Value, Help Text (tooltip shown on the field), and Required (whether the field must be populated on save). (5) Set Field-Level Security to control which profiles can view and edit the field. (6) Add the field to relevant Page Layouts. The entire process takes 5-10 minutes for a straightforward field. Complex formula fields or fields with validation dependencies may take longer to configure correctly.
What is the difference between a Lookup and a Master-Detail relationship in Salesforce?
Both Lookup and Master-Detail are relationship field types that link two Salesforce objects. The key differences are: (1) Ownership and deletion behavior: In a Master-Detail relationship, the child record is owned by the parent — deleting the parent automatically deletes all child records. In a Lookup relationship, the child record can exist independently — deleting the related lookup record removes the association but not the child record. (2) Required field: Master-Detail relationship fields are always required (a child must have a parent). Lookup fields are optional by default. (3) Rollup summaries: Only Master-Detail relationships support Rollup Summary fields (counting or summing child record values on the parent). Lookup relationships cannot have Rollup Summaries natively. (4) Sharing: Master-Detail child records inherit their sharing settings from the parent. Lookup-related records have independent sharing. Choose Master-Detail when records only exist in the context of their parent; use Lookup when records can exist independently.
How do you delete a custom object or field in Salesforce?
To delete a custom field in Salesforce: go to Setup > Object Manager > select the object > Fields and Relationships > find the field > Delete. Before deleting, Salesforce will warn you if the field is referenced by any Apex code, Formula fields, Validation rules, Workflow rules, or Flow automations. All references must be removed before the field can be deleted. Deleted fields are placed in the Deleted Fields section for 15 days, during which they can be undeleted if needed. After 15 days, deletion is permanent. Custom objects are deleted similarly from Setup > Object Manager > select the object > Delete. Deleting an object permanently removes all records stored in that object, so always export data before deletion. Salesforce prevents deletion of objects referenced by other objects’ lookup or master-detail relationships — remove those relationships first.
Problem: Custom Object Relationships Create ‘Too Many Lookups’ Governor Limit Errors
Salesforce limits the number of lookup and master-detail relationships per object (25 relationship fields per object). Organizations that create many custom lookup fields without a structured data model approach can hit this limit and be unable to add new relationships. To avoid this: (1) Audit your current relationship fields before adding new ones — if you are above 15 relationships on any object, review whether all relationships are actively used and remove unused ones. (2) Use junction objects (a custom object with two master-detail relationships) rather than adding multiple lookup fields to a single object when modeling many-to-many relationships. (3) Consider whether a new relationship field is necessary or whether the same data can be stored on an existing related object — fewer relationships mean simpler SOQL queries and better performance.
Problem: Changing Field Types After Data Entry Causes Data Loss
Salesforce supports limited field type conversions — you cannot change a Text field to a Picklist without creating a new field and migrating the data manually. Admins who create the wrong field type and then try to convert it discover they must recreate the field, which may cause existing reports, formulas, and validation rules that reference the old field to break. To prevent field type mistakes: (1) Before creating any new custom field, document the exact data type, field length, and validation requirements with the business stakeholder who requested it. (2) Use Salesforce’s ‘Field Accessibility’ tool to confirm you are creating the field with the correct type for its intended use. (3) For pickslists specifically, choose ‘Picklist (Multi-Select)’ vs. ‘Picklist’ carefully — multi-select picklists cannot be converted to formula fields or used in certain SOQL queries, which limits their use in automation and reporting.
Problem: Custom Field Labels Cause Confusion When Different Teams Use the Same Object
When multiple teams use the same Salesforce object (e.g., the Account object is used by both sales and finance teams), custom fields added for one team may confuse the other team or pollute their page layouts. To manage multi-team field ownership: (1) Use Salesforce Record Types to segregate field visibility by team — create a Sales Account record type with sales-relevant fields and a Finance Account record type showing finance-specific fields. (2) Prefix custom field labels with the owning team name (e.g., ‘Finance: Credit Limit’ vs. ‘Sales: Account Tier’) to make ownership immediately visible when browsing fields in Object Manager. (3) Assign field-level security at the profile level — hide fields irrelevant to a team from their profile view to keep page layouts clean and prevent accidental data overwriting by users unfamiliar with the field’s purpose.
The best Object Manager setup is the one that matches how the business actually uses data. If the structure is vague, the rest of the CRM becomes harder to keep clean.
The best Object Manager setup is the one that matches how the business actually uses data. If the structure is vague, the rest of the CRM becomes harder to keep clean.