Standard Object
A standard object is a pre-built database table that ships with every Salesforce org.
Definition
A standard object is a pre-built database table that ships with every Salesforce org. Account, Contact, Lead, Opportunity, and Case are the best known examples. Each one arrives with predefined fields, relationships, and behaviors that model a common business concept, so you do not have to build the foundation of a CRM from scratch.
You can extend a standard object with custom fields, validation rules, page layouts, and automation, but you cannot delete it or change its API name. That permanence is the point. Most of the platform, and most of the apps on AppExchange, assume these objects exist and are wired to behave a certain way.
How standard objects shape the Salesforce data model
Objects, fields, and records
Salesforce describes an object as the equivalent of a database table. A field is a column on that table, and a record is a single row. The data model is the full set of objects and fields, plus the relationships that connect them. Standard objects are the tables Salesforce gives you on day one, already populated with sensible columns. The Account object, for example, comes with fields such as Account Name, Industry, Billing Address, and Owner. You did not define any of them. They exist the moment your org is provisioned, and they carry validated behavior like address formatting and owner assignment. A record on the Account object is one company you do business with. A record on Contact is one person tied to that company. This table-row-column framing matters because it tells you where data lives and how to query it. SOQL, reports, list views, and the API all address standard objects by their API name, such as Account, Contact, or Opportunity. Learning the standard objects is really learning the shape of the database underneath every screen you see in the product.
The objects every org ships with
Salesforce includes a curated set of standard objects that represent the universal concepts of a customer relationship system. Account holds the companies or people you sell to. Contact holds the individuals at those companies. Lead holds prospects you have not qualified yet. Opportunity tracks a sale or pending deal, and Case tracks a support request. Beyond those headline objects, an org also ships with User, Task, Event, Campaign, Product, Price Book, and dozens more. Some only appear when a related feature or cloud is enabled, such as Contract, Order, or Asset. The full list runs to hundreds of objects across the Sales, Service, and platform layers. The schema and default fields for these objects have been refined over many years. They reflect Salesforce's accumulated opinion about what CRM data should look like. Because that opinion is baked in, the objects behave consistently across every org, which is exactly why third-party tools can integrate with them so reliably.
Standard versus custom objects
The official line is short and clear. Standard objects are included with Salesforce by default. Custom objects are based on standard objects, extend standard functionality, and store information that is unique to an org. You build custom objects yourself when no standard object fits, and their API names always end in the __c suffix. A common mistake is to recreate a standard concept as a custom object. If you build a custom MyCompany Customer object instead of using Account, you lose the integrations, the reports, and the out-of-the-box behavior that other features expect. You also take on the work of rebuilding fields, page layouts, and security that already existed. The better instinct is to customize the standard object first. Add the custom fields you need, adjust the page layout, write the validation rules, and only reach for a custom object when the entity is genuinely specific to your business. A property listing, an inspection, or a warranty claim are good custom object candidates. A customer, a deal, or a support ticket usually is not.
Why integration density favors standard
The biggest practical reason to lean on standard objects is the ecosystem that already understands them. Marketing tools expect a Lead. Document tools expect an Opportunity. Email and calendar sync expect Contact and Activity. When your data lives in the objects these tools assume, the connections work with little setup. Building parallel custom objects to express the same ideas is a well-known anti-pattern. It produces an org that AppExchange packages and native features cannot easily talk to, because they query Account and Contact, not your custom replacements. You end up writing glue code and mapping layers to bridge a gap that did not need to exist. This is not a reason to avoid custom objects altogether. It is a reason to default to standard for anything that maps cleanly to a CRM concept. The integration surface, the reporting, and the long-term maintainability all improve when your core entities sit on the objects the rest of the platform was designed around.
Relationships and record types
Standard objects do not sit alone. They come pre-wired with relationships that mirror real business connections. Contact has a lookup to Account. Opportunity relates to Account and, through Opportunity Contact Role, to the Contacts involved in the deal. Case links to both Account and Contact. These relationships ship ready to use. You can add your own relationships too. A custom object can have a lookup or master-detail field pointing at a standard object, which is how custom data attaches to the core model. A junction object can sit between two standard objects to model a many-to-many link, such as Contacts attending many Events. Record types add another dimension. A single Account object can serve both business and household accounts by using different record types, each with its own page layout and picklist values. This lets one standard object support several processes without splitting your data across tables. The object stays singular, while the experience adapts to context.
Customizing without breaking the foundation
Customizing a standard object happens in Object Manager. You can add custom fields, build validation rules, attach flows and triggers, edit page layouts, and control field-level security per profile. All of this rides on top of the delivered object without altering its core identity. There are limits worth knowing. You cannot delete a standard object or rename its API name, though you can relabel it in the user interface. Some standard fields are required or read-only and cannot be removed. Standard objects also count toward record and storage limits the same way custom objects do. A healthy habit is to audit your standard object customizations on a regular cadence. Fields added years ago for a one-off project tend to linger, page layouts accumulate clutter, and validation rules pile up. Cleanup compounds, so a quarterly review keeps Account, Contact, and Opportunity lean. Treat the standard objects as living tables you maintain, not as a fixed structure you set up once and forget.
How to customize a standard object
You do not create a standard object, since it already exists in your org. What you do is customize it. Here is how to extend a standard object such as Account or Contact in Object Manager using the Lightning Experience setup.
- Open Object Manager
From Setup, type Object Manager in the Quick Find box and select it. You will see every standard and custom object in the org. Click the standard object you want to customize, for example Account.
- Add a custom field
Select Fields and Relationships, then click New. Choose a data type, give the field a label, set the length or options, and save. The new field gets a __c API name even though it lives on a standard object.
- Adjust the page layout
Select Page Layouts, open the layout, and drag your new field onto the appropriate section. Set whether it is required or read-only on that layout, then save so users see the field where it makes sense.
- Add a validation rule
Select Validation Rules, click New, and write a formula that returns true when the data is invalid. Provide an error message and location. This enforces data quality on the standard object without any code.
Where you add custom fields, lookups, and master-detail relationships to the standard object.
Controls which fields and related lists appear, and their order, for users assigned to that layout.
Lets one standard object support multiple processes with different layouts and picklist values.
Set per profile or permission set to hide or expose individual fields independent of the layout.
- You cannot delete a standard object or change its API name, though you can relabel it in the UI.
- Some standard fields are required or read-only and cannot be removed from the object.
- Recreating a standard concept as a custom object breaks integrations that expect Account or Contact.
- Custom fields on standard objects still count toward the per-object custom field limit for your edition.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Standard Object.
Hands-on resources to go deeper on Standard Object.
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. What happens when Standard Object data is not maintained properly in Salesforce?
Q2. Which Salesforce Cloud is Standard Object most closely associated with?
Q3. What best describes the purpose of Standard Object in Salesforce?
Discussion
Loading discussion…