Custom Object
A Custom Object is a user-defined database table created by administrators or developers to store information specific to their organization that is not covered by Salesforce's Standard Objects.
Definition
A Custom Object is a user-defined database table created by administrators or developers to store information specific to their organization that is not covered by Salesforce's Standard Objects. Custom Objects can have custom fields, relationships, page layouts, and security settings just like standard objects, and their API names always end with "__c".
In plain English
“Here's a simple way to think about it: Custom Objects are how an org's specific reality finds room in the schema. Equipment installed, projects executed, inspections run, regulated transactions tracked - entities that don't fit standard objects.”
Worked example
A university using Salesforce creates a Custom Object called "Course Enrollment" to track which students are registered for which classes. The object has lookup relationships to both a Student custom object and a Course custom object, along with fields for Enrollment Date, Grade, and Status. Reports built on this object help advisors identify students at risk of falling behind.
Why Custom Objects are how an org's specific reality finds room in the schema
Standard Objects (Account, Contact, Opportunity, Case) cover the universal CRM concepts. Custom Objects cover everything else. A piece of equipment your service team installs, a project your delivery team executes, an inspection your compliance team runs, a regulated transaction your finance team tracks - each is a custom-shaped record type that doesn't fit a standard object. Custom Objects let you create a dedicated table with its own fields, relationships, page layouts, and security, all using the same platform infrastructure as the standard objects.
The reason restraint is worth practicing here is that Custom Objects are sticky. Once an integration depends on them, once reports reference them, once historical data lives inside them, removing them is a project. Use Custom Objects when the business genuinely needs a new entity (something with its own lifecycle, ownership, and reporting requirements); resist using them as a workaround when a custom field on a Standard Object would do the job. The org you inherit five years from now will be the sum of these decisions.
How to create Custom Object
Custom Objects are how you extend the Salesforce data model — every business has a few things the standard objects don't model. The create flow takes 30 seconds; the longer work is fields, page layouts, and tab configuration afterwards.
- Open Setup → Object Manager → Create → Custom Object
Setup gear → Object Manager → Create button (top-right) → Custom Object.
- Set the Singular and Plural Labels
What the object is called in the UI. "Project" / "Projects" — the Plural drives the tab name and list-view title.
- Confirm the Object Name
Auto-derived from Label, with __c suffix (e.g. Project__c). This is the API name and is **very** hard to change later — get it right now.
- Pick the Record Name field
What the primary identifier is called. Two choices: Text (free-form like "Acme Phase 1") or Auto Number (e.g. PRJ-{0000}). Auto Number is great for numbered tickets; Text for everything else.
- Tick Optional Features
Allow Reports, Allow Activities, Allow Search, Track Field History — turn on the ones you'll need now. They're cheap to enable later but the data only starts flowing from when they're on.
- Decide Deployment Status
In Development = visible only to admins; Deployed = visible to all profiles per their permissions. Most teams flip to Deployed after a few minutes of fields/layout work.
- Save
Object is created. You'll land on the object's Object Manager page — add Fields, configure Page Layouts, optionally create a Tab and add it to your Lightning Apps.
Required. The UI name (e.g. "Project").
Required. The list/tab name (e.g. "Projects").
Required. The API name with __c suffix. Auto-derived from Label — extremely hard to change later.
Required. The label of the primary identifier field (e.g. "Project Name").
Required. Text or Auto Number — pick one, can't change later.
- Object Name (the API name) is essentially permanent. Renaming requires creating a new object, migrating all data + references + dependent metadata. Get the API name right at create time.
- Record Name data type (Text vs Auto Number) is locked after Save. Switching means a new field and migrating all references in formulas, layouts, and code.
- "In Development" is only visible to admins. New objects sometimes ship with content but stay invisible because the deployment status was never flipped to Deployed.
How organizations use Custom Object
Custom Equipment object tracks installed assets; service history per piece of equipment becomes data.
Custom Project object models delivery engagements; lifecycle from sale through completion is tracked.
Related free tool
Trust & references
Straight from the source - Salesforce's reference material on Custom Object.
- Create a Custom ObjectSalesforce Help
- Fields Required for Creating Custom ObjectsSalesforce Help
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…