Custom Object
A Custom Object in Salesforce is a user-defined object you create to model data that does not fit any standard object.
Definition
A Custom Object in Salesforce is a user-defined object you create to model data that does not fit any standard object. Salesforce ships with around fifty standard objects (Account, Contact, Opportunity, Case, Lead, and the rest); Custom Objects extend that schema with the specific record types your business needs. Every Custom Object has an API Name ending in __c (the platform's marker for custom metadata), a set of fields you define, and access to nearly every platform feature that standard objects use: page layouts, record types, validation rules, triggers, formula fields, sharing rules, reports, Lightning Record Pages, and the rest.
Custom Objects are how Salesforce stays usable as a platform rather than just a CRM. A pure CRM database with a fixed schema cannot model the dozens of business-specific concepts every customer eventually needs to track: Projects, Assignments, Service Requests, Invoices, Inventory Items, Patient Visits, Loan Applications, anything else that does not appear on Salesforce's standard list. Custom Objects fill that gap. Most enterprise Salesforce orgs have between thirty and three hundred Custom Objects, each modeling something specific to the business, and the cumulative weight of all those Custom Objects is what makes the org feel like the company's central operational system rather than just a sales tool.
How Custom Objects extend the Salesforce data model
API Name and the __c suffix
Custom Object API names always end in __c (two underscores plus the letter c). The Label and the Plural Label are the display strings users see; the API Name is what triggers, formulas, integrations, and SOQL queries reference. The __c suffix is the platform's marker that distinguishes custom from standard metadata; custom fields also end in __c, and managed-package metadata adds a namespace prefix (NS__Object__c). Pick the API name carefully because changing it after the object has records, integrations, or code references creates a refactoring project, not a click.
Available features
A Custom Object can use almost every platform feature standard objects use. Fields of every type, lookup and master-detail relationships, validation rules, triggers, Flows, Process Builder (legacy), approval processes, page layouts, record types, sharing rules, public groups, list views, reports, dashboards, Lightning Record Pages, Quick Actions, custom buttons, and most Apex features all work on Custom Objects. The exceptions are narrow: some standard-object-specific behaviors (Account-Contact polymorphism, Opportunity forecasting integration, Case escalation rules) do not apply to Custom Objects unless you build the logic yourself. For most enterprise use cases, a Custom Object behaves as a first-class citizen of the platform.
Limits on Custom Objects
Salesforce caps Custom Object count per edition. Enterprise Edition allows 200 Custom Objects per org out of the box; Unlimited Edition allows 2000. Managed-package objects count separately and do not consume the org's quota. Within each Custom Object, the platform caps fields (500 per object on Enterprise, growing to 800 on Unlimited), relationships (40 lookup or master-detail per object, with master-detail capped at 2 per object), and a handful of other resource limits. Hit these limits and you can request increases from Salesforce Support, but the conversation is usually a sign that your data model needs simplification rather than expansion.
Relationships from Custom Objects
Custom Objects can have lookup or master-detail relationships to standard objects and to other Custom Objects. A common pattern is to add an Account lookup on every Custom Object so the records belong to a customer; another is to add an Opportunity lookup to tie Custom Object records to deals. Master-detail relationships propagate sharing and ownership from the parent to the child, which is the right pattern when the child cannot exist independently (Order Item, Quote Line Item). Lookup relationships leave the child independent and are the right pattern when the relationship is optional or many-to-one without ownership semantics.
Custom Object variants
Salesforce ships several variants of Custom Object that behave differently from the standard kind. Big Objects (suffix __b) hold billions of records but lack most platform features (no triggers, no Page Layouts, limited reports); use them for archival and high-volume data only. External Objects (suffix __x) virtualize data from an external system through Salesforce Connect (OData) so you can join external data into reports without copying it. Platform Events (suffix __e) are publish-subscribe event records for integration. Custom Metadata Types (suffix __mdt) are configuration data that deploys with code rather than as runtime records. Pick the variant that matches the use case; choosing the wrong one (Big Object when you needed a standard Custom Object) is hard to reverse.
Triggers and validations
Custom Objects can have Apex triggers, Flows, and validation rules just like standard objects. The trigger framework, governor limits, and bulkification rules apply identically. The data-design decisions matter more for Custom Objects than for standard ones because there is no prior business logic to inherit from: every Custom Object starts as a blank canvas, and the design decisions you make at object-create time (record types, validation rules, sharing model, page layouts) shape what the object becomes over the next five years. Spend the design time up front; retrofitting a poorly designed Custom Object after thousands of records exist is significantly harder than getting it right the first time.
Custom vs Standard Object trade-offs
Every time you create a Custom Object, ask whether a standard object would serve. The standard objects come with platform-specific behaviors (Account hierarchy, Opportunity forecasting, Case escalation, Activity polymorphism) that custom objects do not get for free. If your business concept is close to a standard object's behavior (a Quote-like record, an Opportunity-like deal, a Case-like ticket), use the standard object with record types and custom fields to differentiate. Reserve Custom Objects for concepts that have no standard-object analog. Orgs that create Custom Objects every time a new data shape comes up end up with parallel data models for things the platform already supports, which is harder to maintain and harder to migrate.
How to create a Custom Object
Creating a Custom Object is a foundational admin task. The configuration is straightforward but the design decisions before configuration matter for the life of the object.
- Open Setup and navigate to Object Manager
Setup > Object Manager. The list shows every standard and custom object in the org.
- Click Create > Custom Object
The New Custom Object wizard opens. Pick a Label (singular, e.g., "Service Request"), a Plural Label, an Object Name (API base name without __c, e.g., "Service_Request"), and a Record Name (the Name field's label, often the same as the Label).
- Configure object features
Decide whether to allow Reports, allow Activities, allow Search, allow Bulk API Access, allow Sharing, allow Streaming API Access. Most production objects should enable Reports, Activities, Search, and Sharing; the others depend on integration patterns.
- Save and add custom fields
Open the new object in Object Manager and add the fields the business actually needs. Be deliberate; every field is a Page Layout edit, an FLS configuration, and a potential validation-rule reference.
- Configure page layout, list views, and tabs
Setup > Object Manager > [object] > Page Layouts; List Views; and Tabs respectively. Without these, users cannot interact with the object through the UI.
- Wire into related lists on parent objects
If the Custom Object has lookup relationships to standard objects (Account, Opportunity), add the Related List to the parent's Page Layout so users can navigate to the child records.
- Test through the UI and through Apex
Confirm CRUD works through both the standard UI and any planned automation. Bulkified Apex testing catches governor-limit issues that single-record tests miss.
- Custom Objects cap at 200 per org on Enterprise Edition. Plan before you hit the cap; cleanup is harder than design.
- The API Name (__c suffix) is hard to change after records exist. Pick carefully at creation.
- Master-detail relationships propagate sharing from parent to child; lookups do not. Pick the type that matches the ownership semantics.
- Custom Object variants (Big Object, External Object, Platform Event, Custom Metadata Type) have different behaviors. Pick the right kind at creation.
Trust & references
Cross-checked against the following references.
- Create Custom ObjectsSalesforce Help
- Big ObjectsSalesforce Help
Straight from the source - Salesforce's reference material on Custom Object.
- Create Custom 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 Custom Object?
Q2. Which Salesforce Cloud is Custom Object most closely associated with?
Q3. What happens when Custom Object data is not maintained properly in Salesforce?
Discussion
Loading discussion…