Custom Salesforce Objects: When to Build Them and How
Every Salesforce org eventually outgrows the standard objects. Leads, Contacts, Accounts, Opportunities — they cover most B2B sales motion, but they don't cover everything. When your team starts tracking things in spreadsheets because "there's nowhere to put it in Salesforce," that's the signal.
This guide covers when to build custom objects, how to design them correctly, and the mistakes that create technical debt instead of solving problems.
Estimated read time: 10 minutes
What is a custom object?
A custom object is a database table you define in Salesforce. It has fields, records, relationships, and page layouts — just like standard objects. The difference: you built it for your specific business need.
Examples of custom objects in real orgs:
- Projects — tracking implementation work alongside the Opportunity
- Contracts — managing contract lifecycle separate from Opportunity
- Locations — for field service orgs with multiple sites per Account
- SKUs — product catalog that doesn't fit Products/Pricebooks
- Certifications — tracking employee credentials in an HR context
When to build a custom object
Build a custom object when:
- The thing you're tracking has its own lifecycle — it goes through stages, has multiple records, and needs its own views
- It has multiple related records — one Account has many Locations; you need a one-to-many relationship
- Multiple people interact with it — it needs its own page layout, list views, and reports
- It doesn't fit cleanly into an existing object — forcing it into Activity or a custom field on Opportunity creates confusion
Don't build a custom object when:
- A custom field on an existing object would work
- You're tracking a single value per record (use a field, not an object)
- The data is transient and doesn't need to be queried
The data model decisions
Before you click "New Object," answer these:
What is this object's relationship to existing objects?
- Master-Detail — child is tightly coupled to parent; deleting parent deletes children; roll-up summaries available
- Lookup — loosely coupled; child survives parent deletion; no roll-ups by default
Use Master-Detail when the child record has no meaning without the parent (e.g., Line Item → Opportunity). Use Lookup when the child can exist independently (e.g., Project → Account — the project might outlive the account relationship).
What fields does it need?
Start with the minimum. You can always add fields; removing them requires data migration. Required fields at creation:
- Name (auto-created)
- Owner (auto-created)
- Created Date / Last Modified (auto-created)
Add only the fields you'll actively use in the first 90 days.
What are the sharing requirements?
Does every user need to see every record? Or is this private by default with sharing rules? Set the Organization-Wide Default (OWD) before you go live — changing it later on a large dataset is painful.
Step-by-step: create a custom object
- Setup → Object Manager → Create → Custom Object
- Fill in:
- Label (singular): "Project"
- Plural Label: "Projects"
- Object Name (API name): auto-fills as "Project__c"
- Record Name: what the Name field will be called ("Project Name")
- Data Type: Text (for manually entered names) or Auto Number (for system-generated IDs)
- Configure Optional Features: search, reports, activities, chatter — enable what you'll use
- Set Deployment Status: In Development (until ready for users)
- Save
Now add fields, create page layouts, set up list views, and configure sharing.
The relationship field
After creating the object, add the relationship field that connects it to the parent:
Object Manager → your new object → Fields & Relationships → New → Master-Detail or Lookup → select the parent object.
This creates the foreign key and adds the related list to the parent's page layout automatically.
Common mistakes
1. Too many fields at creation Every field you add is a field someone has to fill in. Start with 5-8 fields. Add more when users ask for them.
2. Wrong relationship type Using Lookup when Master-Detail was right means no roll-up summaries. Using Master-Detail when Lookup was right means accidental record deletion cascades.
3. No sharing strategy Defaulting to Public Read/Write because it's easier. Then six months later, you have a compliance requirement and a painful migration.
4. Duplicating standard object functionality Building a custom "Company" object when Account already exists. Or a custom "Task" object when Activity already handles it.
5. No naming convention Custom object API names like "Stuff__c" or "Data2__c" create confusion for every developer who follows you. Use descriptive names: "Project__c", "Contract_Line_Item__c".
After you build it
A custom object isn't done when you click Save. The work that makes it useful:
- Page layouts — what fields appear in what order, what related lists are visible
- List views — the default views users see when they open the object
- Reports — at least one report type that includes the object
- Validation rules — enforce data quality from day one
- Automation — flows that fire on record creation/update if needed
- Documentation — what this object is for, who owns it, what the fields mean
Want a custom object built for you?
Designing and building a custom object correctly — data model, relationships, page layouts, validation, automation, and documentation — takes a senior Salesforce admin 1-2 weeks.
RevKit's Custom Object Build delivers it in 48 hours for $499:
- Data model design (fields, relationships, OWDs)
- Page layouts for all relevant profiles
- List views and report types
- Validation rules for required fields
- Basic automation (assignment, notifications)
- Documentation
For complex data models with multiple related objects, see Custom Salesforce Development.