The Short Answer
A good Salesforce data model isn't necessarily the most theoretically elegant. Instead, it's one that effectively balances three elements simultaneously: the business process, the permissions model, and the required reporting. Most failing models are built with only the first element in mind.
The big difference between a data model decision and other project decisions is the cost of change. Modifying a Flow might take a day; changing the relationship type between objects after two years of data, automations, and integrations is a project in itself. This is why upfront planning investment pays off more here than anywhere else.
The First Rule: Start with Standard Objects
Account, Contact, Lead, Opportunity, Case, and Product come with capabilities that aren't freely available with custom objects. These include sales processes, Forecasting, Entitlements, Omni-Channel, mobile app functionality, and built-in integration with other products on the platform.
An organization that creates Customer__c instead of using Account will initially have a seemingly cleaner model. However, they'll later discover that every out-of-the-box capability requires custom development. The rule of thumb: deviate from standard only when there's a reason you can state in a single sentence.
When a Custom Object is Necessary
| Scenario | Custom Object? | Justification |
|---|---|---|
| Contract/Subscription with its own lifecycle | Yes | Separate statuses, renewal, ownership, and reporting |
| Installed asset at a customer site | Yes (or standard Asset) | Independent entity with service history |
| Additional "potential customer" | No | This is a Lead or an Account with a Record Type |
| Department within the organization | No | Data about a user, not an entity |
| Complex pricing line items | Depends | Review Quote Line or CPQ before custom building |
Normalization vs. Denormalization: The Reporting Impact
In classical databases, normalization is a virtue. In Salesforce, it's traded against reporting convenience. Each additional relationship level makes building reports difficult without external tools, as standard reporting has limited depth in relationships.
The common compromise is to normalize where data changes and is duplicated, and to selectively denormalize frequently queried fields onto the object used for reporting – provided the duplication is managed automatically, not manually. A duplicated field updated manually will become stale within months.
Permissions Are Part of the Model, Not an Afterthought
The question "who sees what" should be asked when sketching out objects. A model where sensitive data resides on the same object as operational data will later force workarounds – shadow objects, encrypted fields, or opening up overly broad visibility.
The practical test: for every new object, write one line – who owns it, who reads it, who modifies it, and what happens in the hierarchy. If the answer requires more than four lines, the structure likely conflates two entities.
Further details on information sources and update authority can be found in Source of Truth in an Organization, and on managing core entities in Master Data Management.
Scenario: A Software Company that Modeled Around Departments
A medium-sized SaaS company built a model with four custom objects – one for each sales team – because each team had a different process. A year and a half later, teams merged, requiring: report unification, parallel automations in four places, and an internal migration of 60,000 records between objects.
The rebuild centered around a single Opportunity object with Record Types for the different processes. The same business distinctions were preserved – different sales paths, different fields, different Page Layouts – but at the configuration level, not the structural level. The next organizational change will require a Record Type change, not a migration.
The rule that emerged: structure represents entities; configuration represents organizations. What's expected to change every couple of years shouldn't reside in the structure.
Performance and Volume – What Really Matters
Data model performance issues primarily stem from three areas: Data Skew (a single parent with tens of thousands of children, like an "Individual Customers" Account), nested formulas that calculate in real-time across relationships, and large-scale Apex Sharing. All three can be identified during the planning phase by asking how many records are expected under each parent.
Common Risks and Preventive Actions
| Risk | How it appears in practice | Preventive Action |
|---|---|---|
| Unnecessary Custom Object | Out-of-the-box features are manually rebuilt | Check Standard Objects before any new custom object |
| Master-Detail too early | Cascading deletes and an unchangeable structure | Start with Lookup if roll-up isn't needed |
| Model reflecting organization | Every organizational change becomes a migration | Use Record Types instead of objects |
| Data Skew | Locks and slowness during mass updates | Distribute parent records, test volume in planning |
| Permissions as an afterthought | Workarounds and overly broad visibility | Access matrix for each object during planning |
How to Measure Success
| Area | What to Measure | Check Frequency |
|---|---|---|
| Field Usage | Fill rate for each field | Quarterly |
| Reporting | Percentage of reports requiring manual consolidation | Quarterly |
| Structure Stability | Number of structural changes per half-year | Semi-annually |
| Performance | Mass update times and locks | Monthly |
Data model planning as part of overall architecture is performed as part of Integrations and Data Services.
Checklist Before Freezing the Model
- ☐ Each custom object has a one-sentence justification
- ☐ Alternative Standard Objects were checked for each entity
- ☐ Relationship type was explicitly chosen with a justification for Master-Detail
- ☐ Expected volume for each parent was estimated (Skew check)
- ☐ Access matrix: owner, reader, modifier, hierarchy
- ☐ Confirmed all key reports can be built with the model
- ☐ Duplicated fields are updated automatically only
- ☐ Anticipated organizational changes are handled via configuration
- ☐ Up-to-date and documented ERD exists
- ☐ Defined who approves future structural changes
Professional Resources
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations and Data — https://hpi.pro/integrations-data