Salesforce groups objects into four categories based on who created them and where the data lives. Knowing the differences matters because each type has different field limits, API behavior, sharing rules, and reporting capabilities.
Standard objects
These ship with the platform. They have predefined fields, page layouts, validation rules and tab UI. You can extend them with custom fields, but you can’t change their API names or core schema. Examples: Account, Contact, Lead, Opportunity, Case, Campaign, Product2, User, Task, Event.
Standard objects often have specialized behavior baked in — leads convert to accounts/contacts/opportunities, cases support entitlements and milestones, opportunities have stages and forecast categories. You inherit that behavior for free.
Custom objects
These are objects you create to model your business. Salesforce gives them the __c suffix on the API name. They include a full set of standard system fields (Id, Name, CreatedDate, LastModifiedDate, OwnerId, IsDeleted), support page layouts, validation rules, workflow/flow, triggers, reports, and sharing rules. Field limits depend on edition — generally 500 custom fields per object on Enterprise edition (higher with Unlimited).
Use custom objects when no standard object matches the data shape. Common examples: Project__c, Invoice__c, Asset_Inspection__c.
External objects
External objects use Salesforce Connect to point to data stored outside Salesforce — in another database, SAP, an ODBC source, or any system exposing an OData 2.0/4.0 endpoint. They have the __x suffix. The data is not stored in Salesforce; every query hits the external system at runtime.
Key constraints:
- Cannot have triggers, workflow rules, or process-builder/flow record-triggered actions
- Cannot be the master in a master-detail (use external lookup and indirect lookup instead)
- Limited reporting capability
- Subject to callout limits per query
Use when data must remain in its system of record but you want it visible in Salesforce.
Big Objects
Big Objects (__b suffix) are designed to store massive datasets — billions of records — typically for archive, audit trail, or 360-degree history use cases. They are optimized for write-heavy / point-lookup workloads via an index you must define at creation time. You query them via SOQL with the indexed fields or via Async SOQL.
Limitations:
- No standard reports/dashboards (build with Async SOQL → custom object)
- No triggers, no validation rules, no workflow
- Search is limited; you typically query by the defined index
- Records cannot be edited via standard UI
Use cases: storing every page click, retaining 7 years of order line items after archive, audit logs.
Quick comparison
| Object type | Suffix | Data lives in | Triggers | Reports | Typical use |
|---|---|---|---|---|---|
| Standard | (none) | Salesforce | Yes | Yes | Core CRM (Account, Case, etc.) |
| Custom | __c | Salesforce | Yes | Yes | Your custom business objects |
| External | __x | External system | No | Limited | Live link to external system |
| Big | __b | Salesforce (big-data store) | No | No standard | Archive, audit, IoT |
There’s also a fifth, special category sometimes called out: metadata objects (objects like CustomObject, ApexClass, Layout) — these represent setup metadata and are queried via the Metadata or Tooling API, not normal CRUD.
Verified against: Salesforce Help — Object Types and Big Objects. Last reviewed 2026-05-17.