Most Salesforce problems aren't Salesforce problems. They're data problems that Salesforce inherited.
The pipeline that nobody trusts? Data problem. The reports that never match? Data problem. The automations that fire on the wrong records? Data problem. The duplicate contacts that multiply every quarter? Data problem.
And almost all of them trace back to the same root cause: nobody designed the data architecture before the build started.
This guide walks through what good data architecture looks like in a Salesforce org — the decisions you need to make before you configure a single field, and why getting them right early is the difference between an org your team actually uses and one they quietly route around.
Why Data Architecture Comes Before Configuration
When most companies start a Salesforce implementation, they jump straight to configuration — adding fields, building page layouts, setting up automation. It feels like progress. It looks like Salesforce is getting built.
What's actually happening is technical debt accumulating before the system is even live.
Data architecture is the foundational layer underneath everything else in your org. Every report you run, every automation you build, every dashboard your VP checks on Monday morning — they all depend on the decisions you make about how data is structured. Change those decisions later and you're not tweaking settings, you're rebuilding.
The questions you need to answer before you build anything:
- What are the core objects that represent your business?
- How do those objects relate to each other?
- What data needs to be captured — and what doesn't?
- Who owns each piece of data and who can change it?
- How does data move through your process from first contact to closed deal to customer?
Get these wrong and you'll spend the next two years working around them.
Step 1: Map Your Business Process Before You Touch Salesforce
Before you open a single Setup menu, draw your business process on paper. Or a whiteboard. Or a Google Doc. It doesn't matter — the medium isn't the point. The point is that everyone who touches the process agrees on how it actually works.
What you're mapping:
- Where does a record come from? (Web form, manual entry, data import, integration)
- What stages does it move through?
- Who is responsible for it at each stage?
- What information needs to be captured at each stage?
- What triggers happen when it moves forward? (Notifications, tasks, handoffs)
- What does "done" look like?
Do this for every major workflow: leads, opportunities, accounts, cases — whatever applies to your business. It takes time. It also surfaces every disagreement about how the business actually works before those disagreements get baked into the system.
The conversations you have at this stage are the most valuable part of any implementation.
Step 2: Define Your Object Model
Salesforce comes with standard objects — Lead, Account, Contact, Opportunity, Case — that cover most business scenarios. Your first architectural decision is determining when to use standard objects and when to create custom ones.
Standard Objects: Use Them Unless You Have a Reason Not To
Standard objects have advantages you shouldn't throw away: built-in reporting, native mobile support, AppExchange integrations that expect them, and Salesforce's own product investment (new features almost always hit standard objects first).
The mistake most implementations make isn't using standard objects incorrectly — it's creating custom objects when standard objects would have worked fine with some creative configuration.
When Custom Objects Are the Right Call
Create a custom object when:
- You have a distinct business entity that doesn't map cleanly to any standard object
- You need a many-to-many relationship that junction objects would solve
- You're tracking something that runs parallel to (not instead of) your sales or service process
- The data has its own lifecycle, ownership, and reporting needs
Common legitimate custom objects: Projects, Products (when CPQ's product catalog is overkill), Contract Line Items, Locations, Assets, Training Records.
The Custom Object Trap
The custom object trap looks like this: "Accounts don't quite fit our situation, so we'll create a custom object called Companies." Now you've abandoned all the native Account functionality — related contacts, opportunity tracking, activity history — and you're rebuilding it from scratch on a custom object that none of your integrations know about.
Before creating a custom object, ask: can the standard object do this with a Record Type?
Step 3: Plan Your Fields Deliberately
Fields are where data architecture either holds or falls apart.
Every field you add to a Salesforce object is a commitment. Your reps have to fill it in. Your reports depend on it. Your automations trigger off it. Adding fields costs nothing — the real cost is maintaining them, training people to use them, and cleaning up the data when they're used inconsistently.
Required vs. Optional
Be conservative with required fields. Every required field is a field a rep has to fill in to save a record. Too many required fields and reps either skip creating records entirely or fill in garbage data just to get past the validation.
A good rule: a field should only be required if an empty value is genuinely more harmful than incorrect data.
Field Types Matter More Than They Seem
Getting field types right early is one of the most underappreciated parts of data architecture.
| Field Type | Use When | Avoid When |
|---|---|---|
| Picklist | Values are finite and controlled | The list will grow unpredictably |
| Text | Free-form input needed | You need to filter or report on the value |
| Number / Currency | Quantitative data | You'll concatenate it with text |
| Date / DateTime | Time-based tracking | Users need flexibility in format |
| Checkbox | Binary yes/no | There are actually three states (yes/no/unknown) |
| Formula | Derived from other fields | Users need to override the value |
| Roll-Up Summary | Aggregating child records | The relationship is a Lookup (not Master-Detail) |
Picklist Hygiene
Picklist fields deserve special attention because they're almost always the source of dirty data. "Closed Won," "Won," "Closed-Won," and "CLOSED WON" are four different values that mean the same thing — and your reports will split them into four separate rows.
Rules for picklist fields:
- Define the complete list before go-live, not as you go
- Agree on naming conventions with stakeholders (title case vs. all caps vs. sentence case)
- Fewer values is almost always better than more
- Make someone responsible for managing additions
Don't Add Fields You Don't Have a Plan For
"We might want to report on that someday" is not a plan. Every field on a page layout is real estate that competes for your rep's attention. If you don't know what the field is for, why it's required, and who will look at it in a report — don't add it yet.
Step 4: Design Your Object Relationships
How objects relate to each other is the most structural decision in your data architecture. Get this wrong and you can't roll it back without a rebuild.
Lookup vs. Master-Detail
This is the most important relationship decision you'll make.
Lookup Relationship
- Child record can exist independently of the parent
- Deleting the parent doesn't delete children
- Roll-up summaries not available natively
- Ownership and sharing are independent
Master-Detail Relationship
- Child record belongs to the parent — it can't exist without it
- Deleting the parent deletes all children
- Roll-up summaries available on the parent
- Child inherits the parent's ownership and sharing
Choose Master-Detail when the child record genuinely has no meaning without the parent. Choose Lookup when the child record can stand on its own or when the relationship is optional.
The dangerous pattern: choosing Lookup because it feels more flexible, then realizing six months in that you needed roll-up summaries and now your reporting is a mess of workarounds.
Many-to-Many Relationships
When two objects need a many-to-many relationship (a Contact can be related to multiple Opportunities; an Opportunity can have multiple Contacts), Salesforce handles this with a Junction Object — a custom object with two Master-Detail relationships.
Plan your junction objects early. They affect page layouts, related lists, and reporting. Building them in after the fact is painful.
Step 5: Plan Your Sharing Model
The sharing model controls who can see and edit which records. It's one of the most impactful architectural decisions in the system — and one of the hardest to change once data is live.
Org-Wide Defaults (OWD)
OWD is the baseline: the most restrictive access level any user has to a record type. Everything else opens access up from there.
| OWD Setting | Means |
|---|---|
| Private | Users can only see records they own |
| Public Read Only | Users can see all records, edit only their own |
| Public Read/Write | Users can see and edit all records |
Start with the most restrictive setting that makes sense for your business. It's much easier to open access up than to lock it down after the fact.
Roles and Role Hierarchy
Roles determine record visibility up the hierarchy — managers see what their reps see. Design your role hierarchy to match your actual reporting structure, not your aspirational org chart.
Common mistake: creating a deep role hierarchy "just in case" that nobody ever uses and that makes system administration exponentially more complex.
Profiles vs. Permission Sets
Profiles control what users can do. Permission Sets layer additional permissions on top of a Profile for specific users or groups.
The modern best practice is to move away from complex Profiles toward a minimal-access base Profile with Permission Sets for everything else. This is more flexible, easier to audit, and more supportable long-term.
Step 6: Establish Naming Conventions Before Anyone Builds Anything
Naming conventions sound trivial. They are not. In an org built by multiple people over multiple years without conventions, you end up with fields called "Industry," "Industry Type," "Company Industry," and "Ind" — all on the same object, all meaning slightly different things.
Agree on these before day one:
Field labels: Title Case or Sentence case — pick one and stick to it.
API names: These are permanent. A field labeled "Close Date" has the API name CloseDate. Custom fields get __c appended. Once set and used in code or integrations, API names cannot change without breaking things.
Picklist values: Agree on capitalization, abbreviation rules, and who approves new values.
Custom object names: Should be singular nouns. "Project" not "Projects."
Automation names: Include the object name and trigger condition. "Opportunity — Stage Changed to Closed Won" is more useful than "Opp update flow."
This seems like overhead. It saves hours of confusion and supports cleaner handoffs when someone new joins the team or you bring in a second consultant.
The Decisions You Can't Easily Undo
Some data architecture decisions are easy to revisit. Adding a new picklist value is trivial. Adding a field to a page layout takes thirty seconds.
These decisions are much harder to undo after data is live:
Switching a Lookup to Master-Detail — requires deleting and recreating the field, which means losing all existing relationship data.
Changing an API name — breaks every Flow, Apex class, integration, and formula that references it.
Splitting a single object into two — requires data migration, rebuilding relationships, and rewriting automation.
Tightening the sharing model — users who had access lose it. This creates immediate business disruption and often requires exception handling.
Changing the role hierarchy structure — can affect record visibility for every user in the org simultaneously.
Plan these carefully. Build them right the first time.
What Good Data Architecture Looks Like in Practice
A well-architected Salesforce org has a few defining characteristics:
It reflects how the business actually works — not how someone thought it would work six months ago or how a template said it should work. The objects and fields map to real business concepts that real people in the company recognize.
It's conservative about custom objects and fields — every element has a clear purpose and owner. The schema isn't cluttered with things that were added "just in case."
It has clean picklist values and consistent naming — reports produce numbers you can trust because the underlying data is consistent.
It has a sharing model that matches organizational reality — people see what they need to see, nothing more.
It's documented — someone wrote down what the objects are for, what the key fields mean, and why certain architectural decisions were made. This documentation exists even when the person who made the decisions leaves.
The org that becomes a mess doesn't usually fail catastrophically. It fails gradually — one workaround at a time, one extra custom field at a time, one confusing picklist value at a time — until the system is too complicated for anyone to fully understand and too entangled to cleanly fix.
Start With Architecture, Not Configuration
If you're planning a Salesforce implementation — or inheriting an org that's already struggling — the most valuable thing you can do before touching any settings is spend time designing the data model.
Map the business process. Define the objects. Plan the relationships. Set naming conventions. Agree on the sharing model. Get all of that documented and validated by the people who will use the system before a single field gets created.
The builds that go well are almost always the ones where somebody did this work upfront. The ones that go sideways are almost always the ones where nobody did.
Sources
- Salesforce Object Reference for Salesforce and Lightning Platform — Salesforce Developer Documentation
- Data Modeling in Salesforce — Salesforce Trailhead
- Sharing and Visibility Designer — Salesforce Trailhead
- Lookup vs. Master-Detail Relationships — Salesforce Help
- Picklist Field Best Practices — Salesforce Help