Think Before You Build
A foundation session for admins moving toward Data 360 and Agentforce.
Most Salesforce implementations hit a wall because nobody asked the right question. Concepts != tools.
— the reason we're all here today
You can pass the certification and still fail the project.
The clicking is the easy part; the help docs cover it. It's not about the plumbing but the water.
What the docs don't teach is how to think about your data before you build, which determines project success.
Start from the problem, not the plumbing.
"How do we connect our data to Data 360?"
"What's the business problem, and can our data carry the answer through systems?"
Data 360 is an identity system.
What people think it is: a pipe. A connector. A warehouse/lake. A place to put data. …and that framing is exactly what causes the failures I get hired to diagnose.
Its job: decide which records, across all your systems, refer to the same real-world thing. Unified profiles, segments, AI agents are all built on top of that one decision. If it's wrong, everything above it is wrong, too.
Identity & model as load-bearing layer
Wrong identity & models don't throw errors
It produces a confident, wrong answer, which passes it straight up the stack.
- No error fires. The pipeline succeeds. The segment populates. The agent answers.
- It looks like it works. But the segment reaches the wrong people and the dashboard counts the wrong things.
- Wrong, confident, invisible. The agent answers from two companies fused into one — with total fluency.
Before you build anything, ask five questions.
Four about the idea. One about the data underneath it — the one everyone skips.
- Does it drive a specific decision?
- Does that decision matter enough?
- Is it currently made badly?
- Is it suited to AI?
- Can the data actually support it? ← where most ideas die
1 · A decision, not a wish.
"Because of this, ______ will decide whether to ______."
If you can't finish that sentence, you don't have a use case yet — you have a wish. "Give us a 360 view" names no decision. "Surface our best leads so the SDR team decides who to call first" does.
2 · Does the decision matter?
What changes — in revenue, cost, risk, or time — when it's made well vs. badly?
An accurate answer to a question nobody acts on is an expensive science project. If the honest answer is "not much would change," stop here. It's a cheap question that saves real money.
3 · Is it currently made badly?
AI earns its cost on decisions made today by gut, on bad info, or too slowly to matter.
If the decision is already made well by existing means, AI just adds cost without moving the outcome. The gap between how it's made now and how well it could be made, which is where the value resides. No gap, no value.
4 · Is it suited to AI?
AI is for ambiguity, context, and the long tail — not for manufacturing structure the data never recorded.
If the real problem is "we don't have a key that links these two systems," no amount of AI fixes that. It's a missing key wearing an AI costume, a common misroute.
5 · Can the data support it?
An idea can pass 1–4 cleanly and still be foreclosed — because the entity isn't reliably identified, sits at the wrong grain, or has no governed link to what it must roll up to.
This is the one the first four can't answer on their own. You have to go look at the data. Failing Question 5 is failing at the load-bearing layer — so let's spend real time here.
Two shapes of "no."
The identity, grain, or relationship isn't governed. No platform delivers this until it's fixed.
The foundation is fine — the data just hasn't been modeled into shape yet. Build it.
The single most expensive misread
A foundation problem misread as an activation problem = buying a platform to compensate for a governance gap.
So you buy the platform. The platform has to compensate for the gap, so you build a workaround. The workaround needs its own workaround. Three years later there's a stack of compensation nobody can maintain, and the original problem is still underneath it all. This is data debt, and no one is incentivized to fix it.
The identity maturity arc.
Most orgs live at Stage 2–3. Most believe they're at Stage 3–4. That gap is where projects fail.
Forensic data analysis before any config.
- What's really in this table? An "Account" table is often companies AND locations AND franchises, mixed.
- What identifies it, and how reliably? A CRM ID is strong. "Acme Inc." / "ACME LLC" is one company in three coats.
- How much do two systems overlap? Often the honest answer is 3% — when the whole project assumed 90%.
You can answer all three with simple counting queries — before you build a thing.
Four tests for an identity field.
Values rarely repeat across records
personal email shared inbox
It's about the entity itself
their email a spouse's email
Consistently filled in, not sparse
phone 90% filled mostly blank
The value doesn't change often
email job title
Name fails the first test; a fake "na@na.com" fails relevance; a shared corporate phone fails uniqueness. The next two exercises are data that fails them.
What "go look at the data" turns up
Six Account rows. How many real companies?
A different failure shape — grain
Same customer, two different grains.
SUM-44 is a valid foreign key — but to the group, not the store. Join to push spend down and the group's $150K lands on all three stores: a reported $450K. Per-store spend was never recorded — no query recovers it.
This is how you DON'T boil the ocean.
The five questions tell you exactly which data your use case needs. Fix that. Ignore the rest.
Your data doesn't have to be perfect. It has to be good enough for the one thing. That's the difference between shipping value in six weeks and still cleaning data eighteen months later. The five questions aren't a gate, but the flashlight that shows you the short path.
Three things leadership will ask you to build, and what to build instead.
"Build us a Customer 360."
"A 360 view" names no decision (fails Q1). And in a business with both B2B and consumer sides — the same person is a business contact in one system and a consumer in another — merging them on shared email fuses two people who should stay separate.
The one activation that matters most: the single decision a named owner makes today and makes badly. Build identity with rules that keep the two contexts apart. Let that win fund the rest.
"Use AI to clean our data."
It names no decision (Q1). And most "dirty data" is actually a missing key, an absent hierarchy, or a wrong grain — a governance fix, not a model (fails Q4). Each new platform bought to fix the last just adds another layer of compensation.
A fix for the one decision currently made badly because of the data and the single highest-leverage fix that would move it. A scoped, measurable first project instead of an infinite cleanup with no finish line.
"Let the platform figure out our hierarchy."
Matching can bridge "Acme Foods Inc." to "ACME FOODS LLC." It cannot bridge "Naked Juice" to "PepsiCo" after an acquisition, and it can do nothing with "Company Unknown." The link isn't merely weak. It isn't there.
Direct-account-level analysis now, which is the grain the data can actually resolve. Name hierarchy governance as the specific unlock for the family-level version. You're protecting the investment, not blocking it.
The redirection doctrine.
"That won't work." — closes the conversation, makes you the person who says no.
"Here's the version your data can carry today, and here's what unlocks the rest."
Before you connect anything, go look at the data.
Not the documentation — the data. The doc tells you what a field is supposed to contain. A two-line counting query tells you what's actually in there.
Three questions to ask on Monday
- Do I know what my Account records represent? Companies? Locations? Both? Have I looked — or am I assuming?
- What joins my systems together? A real, durable key — or a name holding the whole thing up?
- Could I finish the sentence? "Because of this, ___ will decide whether to ___." On the spot.
Lead with concepts, not tooling. Think before you build.
Glossary, in plain English.
- Entity
- a real-world thing: person, company, account, product
- Identity Resolution (IDR)
- deciding which records are the same real-world thing
- DLO (Data Lake Object)
- your source data, exactly as it arrives
- DMO (Data Model Object)
- that data reshaped into a common format
- Unified Profile
- one record that stands for one real person/company
- Segment
- a group of records you act on together
- Activation
- sending data out to actually do something with it
- Grain
- the level of detail one record represents
- Durable identifier
- a stable ID that doesn't change when a name does
- Governed
- managed with durable IDs, clear owners, and rules