Why successful implementations depend on understanding your data, making smart architectural decisions, and knowing when less is more.

 

Salesforce Data 360 offers organizations a powerful opportunity to connect enterprise data and make it actionable across marketing, sales, service, and AI-powered experiences.

 

But if there’s one thing we’ve learned from working on Data 360 implementations, it’s that connecting systems is rarely the biggest challenge.

 

More often, the real complexity lies in the data itself.

 

Inconsistent customer identifiers, incomplete records, different definitions of the same information, and data models that weren’t designed to work together are challenges we’ve encountered across implementations.

 

And these problems don’t magically disappear once the data reaches Salesforce.

 

Over time, we’ve learned that some of the most important decisions happen before the first data stream is configured: What data should we bring in, where should we transform it and how will the business actually use it?

 

Let’s explore a few lessons from the field.

 

 

1. The Real Challenge: Making Data Usable

 

One of the most common situations we’ve encountered is discovering that data which works perfectly well within individual systems becomes difficult to use when combined.

 

A CRM, a billing platform and a marketing application may each represent customers, products and transactions differently.

 

Individually, those models make sense. Together, inconsistencies begin to surface.

 

A customer identifier may be missing from one source. Product categories may follow different conventions. Relationships among customers, accounts and transactions may not be clearly defined.

 

These aren’t necessarily integration failures. They’re data quality and modeling challenges.

 

Salesforce Data 360 provides Data Lake Objects (DLOs) and Data Model Objects (DMOs) to ingest and harmonize information. But mapping data into a common model doesn’t automatically resolve inconsistencies in its business meaning.

 

And those inconsistencies matter because segmentation, identity resolution, calculated insights and activation depend on reliable data and relationships.

 

A data stream can run successfully while the resulting data model is still unsuitable for the business use case.

 

That’s why we encourage teams to validate not only whether data arrives, but whether it can answer the questions the business needs to ask as well.

 

 

2. Not Every Transformation Belongs in Data 360

 

Another challenge we’ve encountered is assuming that every data transformation should happen inside Data 360.

 

In some projects, source information required extensive cleansing, restructuring or enrichment before it could support the intended use cases.

 

When evaluating the available options, we found situations where performing those transformations within existing source systems was more cost-effective for the client than processing everything in Data 360.

 

This highlights an important architectural principle: Just because a platform can perform an operation doesn’t mean it’s always the best place to execute it.

 

Salesforce provides powerful transformation capabilities, but processing volumes, execution frequency and consumption costs need to be considered.

 

Before designing complex transformation pipelines, we evaluate existing processing capabilities, maintenance responsibilities, data volumes and the overall cost of each alternative.

 

Sometimes, preparing data upstream is the better choice. Other times, native Data 360 transformations make more sense.

 

The goal isn’t to minimize the use of Salesforce. It’s to use its capabilities where they create the most value.

 

When Data 360 Becomes a Temporary Solution

 

There’s another scenario worth highlighting.

 

Sometimes, source data requires significant changes, but fixing those issues in the originating systems will take months.

 

Meanwhile, the business needs to move forward.

 

In these situations, Data 360 transformations can provide a temporary solution, allowing segmentation and activation to continue while upstream improvements are implemented.

 

We’ve seen how this approach can help bridge the gap between immediate business needs and a more sustainable long-term architecture.

 

However, there’s a critical distinction between a deliberate temporary solution and a permanent workaround.

 

A transitional approach should include clear ownership, an expected timeline, and a plan to retire or simplify the temporary transformations once the source systems are ready.

 

Otherwise, what started as a short-term fix can become a permanent dependency, adding processing costs and maintenance complexity.

 

Sometimes, the best architecture isn’t the final architecture. It’s the one that allows the business to move forward while working toward a better solution.

 

 

 

3. More Data Doesn’t Always Mean More Value

 

We’ve also worked with organizations that initially wanted to ingest virtually all the information available across their systems, including years of historical records.

 

The reasoning is understandable: If the data exists, why not bring it all into Data 360?

 

But we encourage clients to ask a different question: How much of that information is actually relevant to the business outcome?

 

Consider a telecommunications company preparing a campaign for customers eligible for a device upgrade.

 

Recent purchases, current contracts, device information and product eligibility may be essential.

 

But does the campaign really need every interaction from 10 years ago?

 

Probably not.

 

That doesn’t mean historical data lacks value. Long-term transaction history can be useful for customer lifetime value analysis, predictive models or understanding purchasing patterns.

 

The key is distinguishing between data that’s available and data that’s actionable.

 

Salesforce’s own usage optimization recommendations encourage importing relevant records and considering aggregation when detailed information isn’t required.

 

Ingesting everything without a clear purpose can increase processing and operational complexity without delivering proportional value.

 

Our approach is to start with the use case, identify the necessary information and determine the appropriate historical window.

 

More data isn’t automatically better data. And more data doesn’t automatically mean better decisions.

 

 

 

4. Identity Resolution Isn’t Always the Main Goal

 

Customer identity resolution is often one of the first capabilities discussed in Data 360 projects.

 

And for good reason. Connecting customer records across multiple systems can be extremely valuable.

 

But not every organization needs to rebuild its identity strategy inside Data 360.

 

Some already maintain reliable customer identifiers in operational systems or enterprise data platforms.

 

In those environments, the immediate challenge may not be identifying the customer. It may be combining existing customer attributes, building meaningful audiences and activating information across channels.

 

Even when identity resolution is necessary, matching rules require careful consideration.

 

Two people might share an email address, while one individual may use several different addresses.

 

The decision should be based on the organization’s identity model, data quality and business requirements.

 

The key is knowing when a capability solves a real problem and when it introduces unnecessary complexity.

 

 

 

5. Zero Copy Doesn’t Mean Zero Complexity

 

Zero Copy allows Data 360 to access supported external datasets without permanently replicating all their records.

 

For organizations with significant investments in platforms such as Snowflake or Google BigQuery, this can be an attractive architectural option.

 

But reducing data movement doesn’t eliminate architectural decisions.

 

We still need to evaluate query performance, source availability, data freshness, supported features and consumption.

 

A dataset used for monthly reporting has different requirements from one supporting a time-sensitive marketing campaign.

 

In some situations, federation is appropriate. In others, ingestion or caching may provide more predictable processing and activation.

 

The best architecture may combine these approaches.

 

Zero Copy should be a deliberate architectural decision, not an automatic preference.

 

 

 

6. Activation Is Where Architecture Gets Tested

 

A technically successful integration doesn’t necessarily translate into a successful customer experience.

 

Imagine a marketing team creating an audience of customers eligible for a new offer.

 

The segment looks correct, and the expected records are present.

 

But when the team activates the audience, some records lack the identifiers required by the destination platform. Or the information arrives too late to support the intended journey.

 

What initially looks like a marketing execution issue is actually an architectural problem.

 

That’s why we recommend defining activation requirements early.

 

Which systems will consume the data? What identifiers do they need? How fresh must the information be? What consent rules apply?

 

These questions should influence modeling, integration patterns and refresh strategies from the beginning.

 

A successful Data 360 implementation isn’t measured by how much data it contains, but by how effectively that data supports business actions.

 

 

 

7. Design for Sustainability, Not Just Go-Live

 

One final lesson: A solution that works on launch day isn’t necessarily sustainable.

 

Data quality needs ownership. Transformations require maintenance. Source systems evolve. Consumption must be monitored. Temporary workarounds need an exit strategy.

 

Salesforce provides capabilities to monitor usage, including Digital Wallet, but operational discipline remains essential.

 

We encourage clients to establish clear responsibilities for data quality, transformation logic, identity rules and activation processes.

 

These decisions help prevent the platform from accumulating unnecessary complexity as new use cases are introduced.

 

 

 

 

 

 

 

Final Thoughts: Start With the Outcome

 

The most valuable Data 360 conversations often happen before anyone starts configuring the platform.

 

They’re about understanding the business problem, challenging assumptions and making architectural decisions that will still make sense as the solution grows.

 

At Devs United, we believe successful implementations start with a simple principle:

 

Use the technology that solves the problem, not every capability the technology offers.

 

Start with a meaningful use case. Identify the data it requires. Understand the dependencies. Validate the activation process. Then expand.

 

Because connecting data is only the beginning. Making it useful, reliable and sustainable is where the real work happens.

 

Frequently Asked Questions

Should we transform data in the source systems or in Data 360?

It depends on the existing architecture, processing capabilities and cost implications. Transforming data upstream can reduce processing requirements inside Data 360, particularly when source systems already support efficient transformation pipelines. However, native Data 360 transformations may be more practical when combining information from multiple sources. We recommend evaluating both options based on performance, consumption, maintenance and long-term ownership rather than assuming one approach is always better.

Can Data 360 transformations be used as a temporary solution?

Yes. Data 360 transformations can help organizations prepare and activate information while underlying data quality or modeling issues are being resolved in source systems. This can support business continuity without waiting for every upstream improvement to be completed. However, temporary transformations should have clear ownership, documented dependencies and a defined transition plan to avoid becoming permanent workarounds.

Is it necessary to ingest all historical data into Data 360?

No. Ingesting all historical data into Data 360 is not required; ingestion should be strictly tailored to specific business use cases. Recent transactions suffice for targeted marketing campaigns, while historical depth is valuable for predictive analytics. Salesforce recommends importing relevant records and considering aggregation when detailed transaction logs aren’t required, balancing business value with storage and processing costs.

Does every Data 360 implementation require identity resolution?

No. Identity resolution is useful when organizations need to match customer records across systems, but it isn’t mandatory for every implementation. Companies with reliable external identifiers may focus on harmonization, segmentation and activation instead. The decision should depend on whether unified profiles are necessary to achieve the desired business outcome.

How can organizations keep Data 360 implementations cost-effective?

Cost optimization starts with architectural decisions. Evaluate which data needs to be ingested, where transformations should occur, how frequently processing should run, and whether federation or caching makes sense. Monitoring consumption through Salesforce Digital Wallet can help identify usage patterns, but regular reviews of data pipelines and business requirements are equally important. The most cost-effective architecture is one that delivers the required business outcomes without unnecessary processing or maintenance.

 

Technical Validation — Official Salesforce documentation

 

These references support the key technical claims in the revised article:

 

 

• Data modeling and readiness: Data Objects in Data 360.

 

• Implementation planning and identity resolution: Get Started with Data 360.

 

• Zero Copy limitations: Zero Copy Data Federation Supportability.

 

• Activation requirements: Activation for Data 360 Segments.

 

• Consumption and credits: Data Services Billable Usage Types and Flex Credits Billable Usage Types.