7 Salesforce Data 360 Mistakes That Sink Projects

If you've watched a Data 360 rollout go sideways, you already know the pattern. Six months in, the credits are burning faster than expected, the unified profiles look weird, and somebody upstairs is asking what exactly they're paying for.

I've been through enough of these now to spot the trouble before it shows up in a status meeting. The funny thing is, the failures rarely come from the technology itself. The connectors mostly work. The identity resolution engine actually does its job. What breaks projects is the stuff that happens (or doesn't happen) before anyone touches a Data Stream.

Here's a rundown of the mistakes I see again and again, plus what to do instead. If any of the terms below sound unfamiliar, salesforcedictionary.com keeps a running glossary of Data 360 vocabulary that's worth bookmarking before your next planning session.

1. Building Without an Outcome in Mind

The first mistake almost everyone makes is treating Data 360 like a data lake. The thinking goes: "Let's pull in everything we have, get it unified, and then figure out what to do with it." Don't.

Data 360 charges credits for ingestion, processing, and activation. Every Data Stream you set up adds to your monthly bill. If you can't trace each source back to a specific use case (a segment, an activation, a feature inside Agentforce), you're paying for storage and processing that delivers zero ROI.

The fix is boring but it works. Pick two or three concrete use cases first. Hot-account scoring for SDRs. Churn-risk segments for retention. Cross-sell triggers for service. Then ingest only the data those use cases actually need. You can always add more sources later, and you probably will.

2. Treating the Data Model Like It's Reversible

Once you ingest data and map it into Data 360 objects (Individual, ContactPoint, Engagement, and so on), you've made decisions that are hard to walk back. The model isn't a draft. Re-modeling means re-ingesting, which means double the credits, double the time, and a long conversation with your project sponsor.

I've seen teams skip the modeling phase because they assume they can fix it later. They can't. Or rather, they can, but the cost is brutal.

Spend real time on the Customer Information Model before you connect anything. Map out which source fields go where. Decide what counts as a Party, what's a Profile, and which records are worth merging into a single unified record. Get a data architect involved if you don't have one in-house. The hour you spend on a whiteboard saves a week of cleanup later.

3. Ingesting Every Field "Just in Case"

This one shows up everywhere. Someone in the kickoff meeting says, "let's just bring it all over and decide what we need later." Two months later, the org has 400 fields ingested across 12 streams, half of them blank, and the credit consumption chart looks like a hockey stick.

Each field you bring in costs storage. Each row costs ingestion credits. Each transformation costs processing credits. None of that is free, and it adds up faster than people expect.

Be ruthless during scoping. If a field doesn't directly serve a documented use case, leave it out. You can add it in a later sprint if a real need emerges. The cost of adding one field later is small. The cost of carrying 200 unnecessary fields for two years is not.

4. Ignoring Identity Resolution Until It's Too Late

Identity resolution is what makes Data 360 worth the price tag. It's how a customer who shows up as [e-mail] in Marketing Cloud and Jennifer Smith in Service Cloud becomes one unified profile. Get it wrong and your activations send the wrong message to the wrong person, and trust in the platform evaporates fast.

Common identity mistakes include relying on email as the only match key (people change emails), not handling household-level matching for B2C use cases, and forgetting about anonymous web visitors who later become known customers.

Before you ingest a single record, write down your match rules. What's the primary identifier? What are the fallback rules? How do you handle conflicts when two sources disagree? Test the rules against a sample dataset and actually look at the unified profiles before you scale up. The work is unglamorous but it pays off every single day the platform runs.

5. Skipping Data Hygiene Before Ingestion

Data 360 doesn't clean your data. It harmonizes it, but garbage in still equals garbage out. If your CRM has 30% duplicate accounts, test contacts using [e-mail], and inconsistent country codes, those problems travel straight into your unified profiles.

I worked on a project where the team was confused why their unified customer count was wildly inflated compared to actual customers. Turned out the source CRM had years of accumulated test records and duplicate contacts that nobody had cleaned up. The fix wasn't in Data 360. It was a six-week data cleanup project in the source systems.

Run a data quality assessment on every source before you connect it. Standardize formats. Dedupe what you can. Tag and exclude test records explicitly. It feels like wasted time until you see how much cleaner your activations work afterward.

6. Forgetting About Permissions and Sharing

This one sneaks up on teams that come from a Sales Cloud admin background. Data 360 has its own permission model. You need specific permission sets for connectors, for the Data 360 home app, for segment creation, and for activation targets. If you don't assign them right, ingestion silently fails or users see empty screens with no clear error message.

The Salesforce help docs cover this, but the gotcha is the order. Some permissions need to be granted before a feature appears in Setup. Others apply to specific connector types only. If you're new to Data 360 permissioning, the Data 360 reference on salesforcedictionary.com has a quick rundown of the permission sets you'll actually need.

Plan permissions during your pre-ingestion phase, not as an afterthought. Document which roles get which access. Keep it tight. Data 360 holds unified customer data, which often has tighter compliance requirements than your source systems do.

7. Activating Before You've Validated

The last mistake is the one with the highest blast radius. You finish ingesting, you build a segment, and somebody pushes "activate" to send the segment to Marketing Cloud Engagement, which fires off an email to 50,000 customers.

Then you find out the segment had a logic error. Or the unified profiles weren't fully resolved. Or the same person got the email three times because the dedupe rules weren't doing what you thought they were doing. Now you're explaining yourself to legal and the brand team simultaneously.

Always run an activation against a test audience first. A handful of internal email addresses, a couple of test phone numbers. Look at what got sent, who got it, how many copies. Compare your segment count in Data 360 against what actually showed up in the destination system. Differences usually point to mapping or identity issues that are way easier to catch on 10 records than on 50,000.

What to Do Differently

The pattern across all seven mistakes is the same. Teams treat Data 360 like a tool you can configure on the fly, when really it's an architectural commitment. The decisions you make in the first 30 days shape what's possible (and affordable) for the next 30 months.

If you're starting a new implementation, do these three things in order. Pick two or three concrete use cases and write them down. Design your data model and identity rules on paper before you connect anything. Bring in clean source data from systems you trust.

Everything else flows from those three steps. Skip them and you'll probably end up on this list yourself.

One more thing. If you're hitting Data 360 vocabulary you don't recognize during planning sessions (Data Stream, Calculated Insight, DMO, Activation Target, Segment Membership), salesforcedictionary.com is a quick way to look up terms without wading through release notes every time.

Have you run into one of these mistakes, or a different one I missed? Drop a comment with what tripped your team up. I'm always interested in hearing what people are wrestling with in real implementations, especially the stuff that doesn't show up in vendor case studies.