Object
An Object in Salesforce is the foundational unit of the data model: a table that holds records of a specific type, made up of fields that describe each record's attributes and relationships to other objects.
Definition
An Object in Salesforce is the foundational unit of the data model: a table that holds records of a specific type, made up of fields that describe each record's attributes and relationships to other objects. Every business entity the platform tracks (a customer Account, a sales Opportunity, a Case from a customer, a Lead from marketing) lives as records on a Salesforce object. The platform ships with around 200 Standard Objects covering common business scenarios, and customers extend the data model by creating Custom Objects for entities specific to their business.
Objects are the right place to start any Salesforce data design conversation because every other element of the platform (fields, validation rules, layouts, automation, sharing, reports, integrations) ultimately attaches to an object. The choice of which standard object to use, when to create a custom object, and how to model relationships between objects shapes everything downstream from the daily user experience to long-term analytics performance.
The shape and behavior of Salesforce objects
Standard versus Custom Objects
Standard Objects ship with the platform and have specific behaviors, permissions, and integrations baked in. Account, Contact, Lead, Opportunity, Case, Campaign, Asset, Contract, Order, Quote, and many more are all standard. They cannot be deleted, their core fields cannot be removed, and many of them participate in standard processes (Account-Contact-Opportunity sales process, Case-to-Contact support process). Custom Objects, by contrast, are created by admins for entities specific to the business, named with a __c suffix (Project__c, Vendor__c, Inspection__c). Custom Objects look and behave like standard objects in most ways but lack the platform-integrated behaviors of standards. Most orgs use a mix, with custom objects extending the model where standard objects do not fit.
Fields, the columns of an object
Each object has fields that describe individual properties of a record. Field types include Text, Number, Currency, Date, Picklist, Checkbox, Formula, Roll-Up Summary, Lookup Relationship, Master-Detail Relationship, and many more. Standard fields ship with the object and cannot be deleted (CreatedDate, OwnerId, Name). Custom fields are added by admins via Object Manager and named with __c (Customer_Score__c, Region__c). Each object has a per-field limit (around 800 custom fields on most objects, lower for Activity), and each field type has its own constraints on size, precision, and behavior. Field-level security controls which profiles can see and edit each field independently of the object's own permissions.
Records, the rows of an object
Records are individual instances of an object: one specific Account named Acme Corporation, one Opportunity for "Acme Q4 expansion deal," one Case with a specific issue. Every record has an Id (a 15- or 18-character unique identifier), an owner, a created timestamp, and the values of all the object's fields. Records can be created, read, updated, and deleted by users with the appropriate permissions, by automation, by Apex code, and by integrations. Each object's records are stored in a multi-tenant database optimized for the platform's query patterns. Records on most objects have a soft-delete behavior: deletion sends them to the Recycle Bin for 15 days before permanent deletion.
Relationships: Lookup and Master-Detail
Objects relate to each other through Lookup and Master-Detail relationships. Lookup is the loose form: a field on object A points at object B (Contact has a Lookup to Account), and the records remain independent. Deleting the parent does not delete children. Master-Detail is the tight form: a field on the child requires the parent (Opportunity Product has a Master-Detail to Opportunity), and deleting the parent cascades to the children. Master-Detail also affects sharing (children inherit the parent's sharing) and enables Roll-Up Summary fields. Choosing between Lookup and Master-Detail is one of the most consequential decisions in the data model because Master-Detail is harder to convert back to Lookup once records exist.
Record types, page layouts, and the per-record experience
Beyond the structural shape, each object can expose different experiences to different users through Record Types and Page Layouts. Record Types segment records into business categories (a Person Account record type versus a Business Account record type, an Enterprise Opportunity versus a Mid-Market Opportunity). Each Record Type can have its own picklist value subset and its own assigned page layout. Page Layouts control which fields, related lists, and actions appear on the record detail page for each profile and record type combination. The same underlying Account object can present radically different interfaces depending on Record Type, Page Layout, and user profile, which is what lets one organization model multiple business scenarios on a single object.
Sharing model and visibility
Every object has a sharing model controlled by Organization-Wide Defaults (OWD): Private, Public Read Only, Public Read/Write, Public Full Access, Controlled by Parent. From the OWD baseline, sharing is opened up through Role Hierarchy, Sharing Rules, Manual Sharing, Apex Sharing, Account Teams, Opportunity Teams, and Case Teams. The sharing model is what determines who can see and modify each record, independent of profile-level object permissions. Profile permissions say "this user can read Accounts in general"; sharing says "this user can read this specific Account." Both must permit access for the user to see the record. Misconfigured sharing is one of the most common sources of "why can't this user see that record" support tickets.
Limits, performance, and scale
Each object has limits that the platform enforces. Most standard objects have unlimited record counts, but performance degrades on lists, reports, and SOQL queries against very large objects (more than 10 million records). Custom objects have governor limits on storage (file storage, data storage), per-object field counts, and per-relationship counts. Activity objects (Task, Event, EmailMessage) are notoriously hard to scale because they sit in a different storage tier with their own limits. Designing for scale on the data model side means thinking about archive strategies, partitioning strategies (multiple objects with the same shape for different lines of business), and where Big Objects (a different storage tier for write-mostly archival data) belong.
Create and configure an object
Creating a custom object is one of the more common admin tasks on the platform. The walkthrough below covers the standard sequence from initial setup through deployment and adoption. The same general flow applies whether you are modeling a new business entity or extending the data model to support a new use case on an existing entity.
- Design the object before clicking anywhere
Sketch the object on paper or in a diagramming tool. Document its purpose, expected record volume, relationships to other objects (Lookup or Master-Detail), record types, and major fields. Validate the design with at least one business stakeholder. Most data model regret traces back to skipping this step, then realizing two months later that the object should have been a related list on an existing object rather than its own entity.
- Create the object in Object Manager
From Setup, navigate to Object Manager, click Create, and pick Custom Object. Fill in the Label, Plural Label, Object Name (API name), and Record Name field type. Enable Allow Reports, Allow Activities, and Track Field History as appropriate. Save. The object now exists with a Standard Name field plus the audit fields the platform always adds (CreatedDate, OwnerId, LastModifiedDate). Open the object's setup page to begin adding fields.
- Add fields and relationships
Add the custom fields the business needs, one at a time. For each field, pick the type carefully (a Picklist that should have been Text is hard to convert, and vice versa). Add the relationships to other objects, choosing Lookup or Master-Detail per the design. Set field-level security on each field for each profile. Group the fields logically on the page layout. Add validation rules for required field combinations or business-rule enforcement.
- Configure permissions, layouts, and roll out
Grant object permissions through profiles or (better) permission sets. Configure the page layout for each Record Type and assign per profile. Add the object to the relevant app menu so users can access it. Build a basic report type if the business will report on the object. Train the impacted users via a brief written guide. Communicate the new object's purpose so users know when to use it versus existing standard objects.
The display name and plural form shown in the UI for the object. Required at creation time.
The programmatic identifier ending in __c. Used in formulas, Apex, and integrations. Cannot be renamed easily.
Either a Text field or Auto Number, used as the primary display label for records.
Required to create custom objects and configure their fields, layouts, and permissions.
Without page layout assignment and object permissions, users cannot see or interact with the new object.
- Object Name (API name) is hard to change after records exist. Set it carefully on creation; rushing this leads to confusing inconsistencies later.
- Master-Detail is hard to convert to Lookup after records exist. Use Lookup as the default unless cascade-delete and Roll-Up Summary are specifically required.
- Field-level security is independent of page layout. A field can be on the layout but hidden by FLS, which surprises users who expect to see it.
- Activity-related objects (Task, Event) live in their own storage tier and have unique limits. They do not behave the same as other custom objects.
- Custom objects do not automatically appear in app navigation. Add them to the relevant app or users will not find them.
Trust & references
Cross-checked against the following references.
- Create a Custom ObjectSalesforce Help
- Standard ObjectsSalesforce Help
Straight from the source - Salesforce's reference material on Object.
- Object ReferenceSalesforce Developer Docs
- Custom FieldsSalesforce Help
- Relationships Among ObjectsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Who would typically configure or interact with Object?
Q2. What best describes the purpose of Object in Salesforce?
Q3. What happens when Object data is not maintained properly in Salesforce?
Discussion
Loading discussion…