Good Salesforce data model design starts with the process and the reports you need, not with new objects. Reuse a standard object when its built-in behavior fits the job, because you inherit features, reports and future releases for free. Create a custom object when the thing you track has its own life cycle and no standard home. Then choose lookup or master-detail relationships based on ownership, sharing and roll-ups you need.
Where should data model design start?
Start with the business process and the questions leadership will ask of it. The objects follow from those answers, not the other way round.
Write down the nouns in the process: the things people create, hand off, approve and count. A project, an installed asset, a subscription or an application is a noun. Statuses, dates and amounts are usually fields on those nouns, not objects of their own.
Next, list the ten reports or dashboards the process owner expects in the first quarter after launch. Each one tells you which records must be related and at what grain. If a report needs one row per renewal, a renewal is probably a record. If it only needs a renewal date, a field will do.
- Who creates each record, and who owns it afterward?
- How many of these records will exist in a year, and in five?
- Which records must be deleted, or kept, when a parent goes away?
- Who must not see these records, even inside the same team?
- Which totals must appear on the parent without anyone running a report?
Those answers drive almost every relationship decision later. Skipping them is how orgs end up with three objects that all mean customer.
Which standard objects should we try first?
Try the standard object that already models your noun before building anything new. Standard objects carry features a custom object would have to rebuild.
Account and Contact hold the organizations and people you deal with. Opportunity tracks a potential sale through stages with amounts, forecasting and products. Case handles a customer request or issue with queues, assignment and entitlements. Asset records a specific product a customer owns or uses. Contract holds agreement terms and dates, and Order captures what a customer committed to buy. Product and price books define what you sell and at what list price.
Each comes with page behavior, reports, list views and automation hooks that Salesforce keeps improving. Many AgentExchange (formerly AppExchange) apps and integrations also expect data in these objects. A custom Customer Request object would miss all of that.
When is a custom object the right call?
Build a custom object when the thing has its own identity, life cycle and reporting, and no standard object means the same thing. Do not build one just to hold a few extra attributes.
Good candidates include a phased project, a subscription tracked over time, an application under review, or an asset inspection. Each has its own owner, statuses and history. A weak candidate is a single extra address or a yes-or-no flag that belongs on an existing record.
In our broker-dealer build, the firm needed to follow both issuers seeking capital and the investors backing each deal. No standard object fit, so the team built custom Engagement and Investment objects. Junction objects handled the many-to-many links between them. Flows created the commission-split records. Validation rules blocked a deal from going to market until compliance steps were done.
For where custom objects sit within wider customization choices, our custom versus configuration article covers code and declarative trade-offs.
Should we use a lookup or a master-detail relationship?
Use master-detail when the child cannot exist without its parent and should share its access. Use a lookup when the child stands on its own and needs its own owner.
In master-detail, the detail record has no owner of its own. It inherits ownership and sharing from the master, and deleting the master deletes its details. You also get roll-up summary fields on the master, such as the count or total of related records. Salesforce help documents a default of 25 roll-up summary fields per object, raisable to 40 through Support.
A lookup is looser. The child keeps its own owner and sharing settings, and the field can be optional. When the parent is deleted, you choose whether to clear the field or block the deletion. Roll-ups across lookups need Flow, Apex or an AgentExchange tool.
Limits shape the design too. A custom object can have at most two master-detail relationships. Lookup and master-detail fields together default to 40 per object, with Support able to raise that toward a hard ceiling of 50. A standard object cannot sit on the detail side of a master-detail relationship with a custom object.
How do we model many-to-many and outside data?
Use a junction object for many-to-many links, and an external lookup when the parent record lives outside Salesforce.
A junction object is a custom object with two master-detail fields, one to each side. A course enrollment linking students and courses is the classic example. Each junction record can carry its own fields, such as role, percentage or start date. The first master-detail field you create becomes the primary relationship and drives the record's look and ownership.
External lookups link a Salesforce record to an external object surfaced through Salesforce Connect. They match on the external object's External ID field rather than a Salesforce record ID. Salesforce Connect is a separate paid add-on in most editions, so confirm availability with your account team.
How should fields be designed so they stay usable?
Pick the narrowest field type that fits, prefer picklists for anything you will report on, and describe every field. Field sprawl is easier to prevent than to clean up.
- Picklists beat free text for status, category or reason. Text fields produce ten spellings of one value and unusable reports.
- Formula fields calculate on read and never go stale. Store a value instead when you need history, filtering on large volumes or a point-in-time snapshot.
- Use number, currency, date and checkbox types for what they are. A date stored as text cannot drive a date filter or reminder.
- Give each field a clear label, an API name that matches, a description and help text. The description is for admins; help text is for users.
Custom field allocations vary by edition. Salesforce help lists 500 per object for Enterprise Edition and 800 for Unlimited Edition, with lower figures for smaller editions. Treat those as ceilings, not budgets. An object nearing them is usually an object doing several jobs.
How do ownership and sharing affect the model?
Every object decision is also an access decision. Settle who owns each record and who may see it before fields are built.
A lookup child gets its own organization-wide default and can have sharing rules. A master-detail child is controlled by its parent, which keeps access simple but removes per-record control. If a child must be visible to people who cannot see the parent, master-detail is the wrong choice.
Our sharing model guide explains organization-wide defaults, roles, sharing rules and implicit access in depth. Read it alongside this article before finalizing relationships.
What does the model mean for reporting and data volume?
Reports can only follow relationships that exist, so model the joins your reports need. Plan for volume early on objects that will grow quickly.
Salesforce creates standard report types for many relationships, but cross-object reports often need a custom report type. Custom report types also let you show parents with or without related children, which matters for questions like accounts with no active subscription.
Large volumes change design choices. A single parent holding a huge number of children, or one owner holding a huge share of records, can cause locking and sharing slowdowns. Avoid catch-all parent records from day one, and plan retention for high-churn objects. Our sharing and archiving guides cover skew and retention.
Do custom objects affect licensing or industry clouds?
Yes, both can change what you build. Platform licenses cap custom object access, and industry clouds ship their own data models.
Platform licenses give users access to accounts, contacts and a limited number of custom objects, without core CRM objects like Opportunity or Case. Platform license tiers cap how many custom objects those users can reach. Check the current allowance with your Salesforce account team.
Licensing also shows up in less obvious ways. In an industrial-services rescue, the team built a custom Labor Resource object to track outside contractors and their certifications. That let the firm track field labor without a Field Service license for every worker.
Industry clouds such as Financial Services Cloud, Health Cloud and Manufacturing Cloud include prebuilt objects for their domains. If you plan to adopt one, build on its model instead of recreating it. Our guide to choosing a Salesforce cloud covers that decision.
Which object should we reach for first?
| Need | Try first | Go custom when | Watch out for |
|---|---|---|---|
| Track projects after a sale | Opportunity or Order for the sale itself | Projects have phases, owners and timelines separate from selling | Renaming Opportunity to Project and breaking forecasts |
| Track installed equipment | Asset | You need inspection or maintenance history per unit beyond Asset fields | Duplicate asset records created by integrations |
| Track subscriptions or renewals | Contract, Order or Asset | Each term needs its own status, usage or billing details | Overlap with CPQ or billing products already licensed |
| Manage service requests | Case | Rarely; Case usually fits with record types | Building a parallel ticket object that skips queues |
| Process applications or reviews | Case or Opportunity if the steps match | Steps, reviewers and outcomes differ clearly from both | Free-text decision fields that cannot be reported |
| Link many records to many records | Standard related lists such as Contact Roles | Each link needs its own fields | Forgetting which master is primary on the junction |
How do we document the model and change it safely later?
Draw the model before you build it, keep the diagram current, and treat changes to live objects as releases. Most painful rework comes from undocumented relationships.
Schema Builder in Setup shows objects, fields and relationships as a diagram and lets you add them visually. Many teams also keep an entity relationship diagram in their documentation tool. Our org documentation guide covers what to record and where.
Changing a live model takes care. Converting a lookup to master-detail requires every child record to have a parent first. Deleting or retyping a field can break reports, flows, integrations and page layouts. Search for dependencies with the Where Is This Used button on custom fields, test in a sandbox, then deploy.
- Add new fields and objects freely, but describe them on creation.
- Hide or deprecate fields first, and delete them only after a full reporting cycle.
- Back up data before retyping fields or changing relationship types.
- Tell report owners and integration owners before the change ships.
