Salesforce Data Cloud (Data 360): Questions to Ask Before You Implement

Salesforce Data Cloud (now called Data 360) is easy to get wrong. You can connect a source and ingest data in an afternoon, but beyond that, working with Data 360 is not straightforward - with lots of different metadata types that cannot be driven from an SFDX project, it's mostly point-and-click. Once configured, D360 does what it's built to do: unify profiles, resolve identity, and activate segments. But the setup process is often slow, heavily manual, and offers limited error diagnostics. Because of that, we've found that end-to-end schema design and deployment cannot be reliably delegated to an AI assistant like Claude.

What's more, the platform asks you to make a commitment before you have even answered the questions necessary for that commitment to be a sound one. The decisions made about your data model, identity resolution rules, and architecture in week one will affect you for many years.

In our experience, most failed implementations fail because the team expected that Data360 should behave as a system it was not meant to be, and no tough questions were asked prior to the activation of the first data stream.

This is a guide to those questions. Work through them before you get started.

Salesforce Data 360 is a customer data platform, which is a unification and activation platform. It aggregates information from multiple sources, reconciles identities and creates unified profiles, creates segments and insights, and activates the latter by sending the data out to systems that perform the actions. It is a system of record. It is not your master data management platform, your consent platform, your DMP, your ETL, or your data warehouse. Just about every nasty surprise comes because you confuse it for one of those.

Before you ingest a single source

Many organizations skip the preparatory stage. There's a tendency to think about Data 360 as a dumping ground: bring everything in now, figure out the categorization and mappings later. Don't fall into this trap. Adjusting categorizations and data-model mappings at a later date is neither cost-free nor quick.

We strongly recommend that you create a data dictionary for your sources before you start bringing in any data. Specifically, you need to know about each source:

• Relationships. Primary and foreign keys, and which fields are nullable.
• Governance. Honest estimates of data quality, expected volumes, and how the data flows.
• Overlap. Where this source shares data points with others, and what that implies for matching.

Then answer four questions per source:

• Quality. Is the source inconsistent or incomplete? What are your rules for consuming it anyway?
• Transformation. Will you cleanse and transform before ingestion, or during it inside Data 360? Both are valid but do not drift into one by accident.
• Data types. Do any specific types need to be supported? Inspect and align them between source and platform.
• Primary keys. Is there a unique identifier per stream? If not, build one with a formula field. You should know that the primary key is enforced at the data stream level, not the data model object. The key on your DLO is not the key on your DMO.

Behind all four, identify the system of record for each of these sources. If you can't determine what system is the system of record for a particular domain, then you're not ready to ingest it.

The five questions about the source itself

Pressure-test each data source across five dimensions.

• Volume. How much data do you actually need to satisfy the use case? Are you about to ingest data that nobody needs? How much history matters? How will it grow? Storage and consumption are not free, so "have it just in case" is potentially a rather costly decision.
• Value. How does this data serve a business objective? What decision gets made with it? If you can't name the decision, question the ingestion.
• Veracity. Can you trust it? The "garbage in, garbage out" phrase is somewhat overused, but it holds here.
• Velocity. How "fresh" does it need to be? Streaming costs more than scheduled batch — not at ingestion, which is zero-cost on the internal Salesforce connectors either way, but in the downstream processing that real-time drives and the pipeline you have to run and maintain. Pay for speed only where the use case demands it.
• Variety. Is it structured, unstructured, or denormalized? Each shape carries downstream transformation and privacy implications.

The architecture questions

Get these two decisions right at the start of the project.

Where Data 360 lives, and how it connects to your CRM

Data 360 can be deployed either in an existing Salesforce org or in a new, dedicated Salesforce org.

Home org. When Data 360 is the home org to your CRM, you get the richest integration: Profile Explorer, the Data Processing Engine writing unified identities and insights back into the platform, data actions and platform events, and direct Apex query access. Some of these functionalities are available only when using the home org.

Non-home org. In case Data 360 is in another org that is different from the one used by your CRM, then authentication is done through named credentials and a connected app, and then surfaced into the CRM via custom Lightning Web Components.

If you already have your CRM set up in a region where Data 360 is not yet locally available, you may find yourself being forced to create a brand new org now, followed by migration at a later date. Tooling can help with the migration, but don't count on the same level of automation in the setup process. The cost of this technical debt should factor into your planning.

Keeping brands, geos, and teams separate

When managing multiple brands or geographies within a single instance, Data Spaces offer logical partitioning. Ingest the source only once and then relate it to one or more Data Spaces to create identities, insights, and segments within those spaces individually. All capabilities become Data Space aware, and you provide users access based on those spaces as per compliance requirements. On activation into Marketing Cloud, BU-aware activation maintains data for each business unit separately and allows segment sizing according to business units. Define your segmentation model before defining the data model.

Identity resolution is a business decision

Unification is where Data 360 earns its keep, and where teams most often reach for a default and regret it.

• Don't match on the contact point alone. Email or phone by itself is not a safe match rule. Shared email addresses and reused phone numbers will merge people who are not the same person.
• There is no universal "right" consolidation rate. It varies by industry, by customer, by scenario. More permissive match criteria consolidate more aggressively. More restrictive criteria consolidate less and stay closer to the original source records. Neither is correct in the abstract.
• Decide by consequence. Ask what happens if you wrongly merge two individuals. In some businesses, that's a minor annoyance, but in others it's a privacy breach or a safety issue.
• Test before you commit. Use multiple identity resolution rulesets and identity graphs to compare how different criteria change the consolidation rate, then choose with evidence.
• Use the right identifiers. Party identification lets you match on external and third-party identifiers like license numbers, device IDs, and loyalty numbers, which are far stronger signals than a shared email.

What's next

The majority of the work of a successful implementation takes place before ingestion, in the answers to straightforward questions. What is the purpose of this data? Who owns the truth behind this data? Which decision does this make? What occurs if the identity resolution process incorrectly merges two identities? Where is the platform deployed, and how is it accessed by the executing systems?

Ask those first. The platform is fast enough that you can afford to slow down at the start, and the groundwork pays off for years.

Having answered these questions correctly turns a Data Cloud implementation from a gamble to a decision you can rely on.

If you want a second set of eyes on your Data 360 plan before you commit, send us your source list and the questions above. We'll tell you what's ready to ingest, what needs answering first, and what your architecture should look like.

connect@aquiva.com

---

Frequently asked questions

Is Salesforce Data Cloud (Data 360) an MDM? No. Data Cloud is not a Master Data Management system. It unifies data and resolves identity for segmentation and activation, and it may enhance an MDM, but it is not built to master a golden record and federate it back to your source systems.

Can Data Cloud cleanse and transform messy source data? Only up to a point. Data Cloud is not an ETL tool for fixing data quality. Its transforms are for enriching and reshaping data that is already clean and merged, so cleanse at the source first. When you connect multiple sources, use fully qualified keys so records that share primary or foreign keys don't collide.

Can Data Cloud replace a consent management platform? No. Data Cloud is a system of reference for consent: it can ingest, store, and segment on consent signals, but it does not resolve conflicts between them, de-duplicate them, or master a single source of truth. Use a dedicated platform such as Salesforce Privacy Center or OneTrust for that.

Is Data Cloud a DMP, and can it replace Audience Studio? Not directly. Data Cloud does not generate third-party cookies. It manages both known and anonymous data and activates audiences to programmatic and premium partners, but it centers on unified known profiles rather than anonymous, cookie-based audiences.

Does Data Cloud handle householding automatically? No. Data Cloud does not natively group household members or build segments on household logic. If household identifiers are passed in and mapped, it can store and maintain those relationships.

Can Data Cloud do waterfall segmentation? Not as a standalone feature. Data Cloud can create nested segments and apply exclusion criteria. The recommended pattern is to combine Data Cloud with Marketing Cloud Engagement to produce mutually exclusive segments.

Can one web tag send data to both Data Cloud and personalization? Not clean today. The recommended sequence is to implement personalization first, then feed Data Cloud through the personalization connector. Leading with the Data Cloud web tag means tearing out the tag and sitemap and redoing the setup later.

Should I provision Data Cloud on my existing Salesforce org or a new one? It depends on integration needs. Running Data Cloud as the home org to your CRM gives the richest native integration: Profile Explorer, Data Processing Engine write-back, and direct Apex query access. A separate org is more flexible and connects through named-credential authentication and a connected app.

Can I bulk export unified profiles from Data Cloud to Snowflake? Harmonized bulk export is not what the platform is designed for. Use zero-ETL data sharing instead. You can publish segments through activation, access raw data through API and JDBC, and request profile-level exports where needed.