Strategy in the Clouds

Introduction: Why Implementation Order Matters

Salesforce Data 360 offers organizations the ability to bring data together from multiple sources, create unified customer profiles, generate actionable insights, and activate data across business applications.

But getting value from Data 360 involves more than connecting a few systems and building customer segments. Each stage of the implementation builds on the work completed before it.

If data is poorly mapped, identity resolution may not produce the expected results. If customer identities are not resolved when a use case depends on unified profiles, segments may not represent the intended audience. And if the business requirements are unclear, teams can spend time building capabilities that don’t address the organization’s most important needs.

A successful Data 360 implementation starts with the business outcome and works backward to determine the data, configuration, and activation capabilities required to achieve it.

In this article, we’ll walk through a practical implementation sequence, explain why each step matters, and identify checkpoints that can help your team avoid unnecessary rework.

Step 1: Define the Business Objectives and Use Cases

Before configuring Data 360, establish what the organization wants to accomplish.

It can be tempting to begin by connecting data sources or exploring platform capabilities. However, starting with the business objectives helps the team determine which data is needed, which features must be configured, and what success should look like.

For example, an organization might want to:

• Create a more complete view of its customers across multiple systems.
• Improve marketing segmentation and personalization.
• Give sales and service teams access to more relevant customer information.
• Calculate customer lifetime value or other business metrics.
• Identify customers who may be at risk of leaving.
• Provide relevant customer context to AI-powered experiences.

Each use case can have different implementation requirements. Some require unified profiles, while others may rely on modeled data, calculated insights, or other capabilities.

For each use case, document:

The business problem: What challenge is the organization trying to solve?

The desired outcome: What should improve once the solution is implemented?

The required data: Which customer attributes, transactions, events, or other information are needed?

The intended users or systems: Who will consume the data, and where will it be used?

The success measures: How will the organization determine whether the solution is working?

For example, if the objective is to improve marketing campaign targeting, relevant success measures might include audience accuracy, campaign engagement, conversion rates, or reduced irrelevant communications.

Defining these requirements early creates a foundation for the remaining implementation decisions.

Checkpoint: The team has agreed on the initial use cases, required data, intended outcomes, and measurable success criteria.

Step 2: Assess the Data and Establish the Implementation Foundation

Once the use cases are clear, determine whether the organization has the data and platform foundation needed to support them.

This step involves evaluating the source systems, understanding the available information, and establishing the necessary access, permissions, governance, and architecture.

Identify the source systems

Create an inventory of the systems that contain relevant data.

Depending on the use case, these might include:

• Salesforce CRM
• Marketing Cloud Engagement
• Marketing Cloud Next
• Website and mobile applications
• Transaction or billing platforms
• Customer service systems
• External databases and data warehouses

For each source, document the data available, its owner, how frequently it changes, how it can be accessed, and any known quality issues.

Assess data quality

Review whether the required data is complete, consistent, and sufficiently reliable.

For example, do customer records have stable identifiers? Are email addresses consistently formatted? Are transaction dates available? Do different systems use the same customer ID, or will the organization need alternative matching criteria?

These questions help identify potential issues before the data is integrated.

Establish governance and access

Confirm that the appropriate licenses, connections, permissions, data access controls, and privacy requirements are addressed.

Data governance should not be treated as a task that happens only after the data has been connected. Decisions about consent, sensitive information, permitted uses, and access should inform the implementation from the beginning.

Checkpoint: The team understands its source data, integration requirements, known data quality issues, access requirements, and governance obligations.

Step 3: Connect Data Sources and Configure Data Streams

With the business requirements and source assessment in place, the team can begin bringing data into Data 360.

Data streams are used to ingest data from supported sources. Depending on the connector and configuration, data can be processed in batches or through streaming patterns.

When configuring data streams, consider:

• Which objects, tables, files, or events need to be ingested.
• Which fields are required for the use case.
• How frequently the data needs to be refreshed.
• Whether historical data is required.
• How updates and deletions should be handled.
• How ingestion success and failures will be monitored.

It is generally more effective to begin with the data required for the prioritized use cases rather than attempting to ingest every available source at once.

For example, if the initial use case is to identify customers who purchased a product but have not engaged with a related service, the team might start with customer information, transaction data, and the relevant engagement records.

Additional sources can be introduced as new use cases are prioritized.

Validate ingestion before moving forward

Once the data streams are configured, confirm that data is arriving as expected.

Check record counts, required fields, refresh behavior, and whether the ingested data reflects the source system accurately.

In Data 360, ingested records are represented in data lake objects, commonly referred to as DLOs. These provide the foundation for the subsequent data modeling process.

Checkpoint: Required data streams are operational, expected records are available, and ingestion issues have been investigated.

Step 4: Map Data to the Data 360 Data Model

Ingesting data is only part of the process. Data 360 also needs to understand what the data represents and how it relates to other information.

This is where data mapping becomes essential.

Data lake objects contain ingested source data. Data model objects, or DMOs, represent standardized business concepts within the Data 360 data model.

Mapping connects the fields in the ingested data to the appropriate fields in the data model.

For example, a source system might use a field called Customer_Email, while the standardized data model uses a corresponding email field on a contact point object.

Mapping establishes how those fields relate.

Why data mapping matters

Correct mapping helps ensure that downstream capabilities can use the data as intended.

A field that exists in an ingested source does not automatically become available for every segmentation, identity resolution, or activation scenario. The necessary objects, fields, and relationships must be configured appropriately.

For custom data streams, teams should pay particular attention to required primary keys, event timestamps where applicable, and the relationships needed for the intended use cases.

Validate the data model

Before proceeding, verify that:

• Required source fields are mapped to the correct data model fields.
• Primary keys and required event fields are mapped appropriately.
• Relationships between relevant objects are configured.
• Data types and values are consistent with expectations.
• The resulting modeled data supports the intended use cases.

For example, if customer records and transaction records are both available, the team must ensure that the modeled relationship between customers and transactions supports the analyses or segments being developed.

Checkpoint: The required data is correctly mapped and related within the data model, and the modeled records have been validated.

Step 5: Configure Identity Resolution and Validate Unified Profiles

If the use case requires a unified view of individuals, accounts, or other supported entities, identity resolution is the next major consideration.

Identity resolution helps determine which records across different data sources belong to the same entity.

The process uses configured matching rules to identify records that should be linked. Reconciliation rules determine how conflicting values are handled in the resulting unified view.

For example, a customer may have one record in CRM, another in a marketing platform, and a third in a transaction system. Identity resolution can help connect those records when they meet the configured matching criteria.

Why should identity resolution follow data mapping?

Identity resolution depends on correctly modeled data and the availability of appropriate identifiers.

If key fields are missing or mapped incorrectly, the matching rules may not perform as intended.

This is why teams should validate the source data and mapping before relying on unified profile results.

Validate the results

Once the identity resolution ruleset has been configured and run, review the output.

Ask questions such as:

• Are records that belong to the same customer being linked?
• Are records belonging to different customers being linked incorrectly?
• Are there unexpected numbers of unified profiles?
• Are important records remaining separate?
• Are reconciliation results consistent with the business requirements?

The objective is not simply to produce unified profiles. It is to produce results that are appropriate for the intended business use case.

One important distinction: unified profiles link related records; they do not automatically clean every source record or establish an authoritative master value for every attribute.

Checkpoint: Identity resolution has been configured where required, and the resulting unified profiles have been reviewed against expected outcomes.

Step 6: Create Calculated Insights and Other Derived Metrics

Once the underlying data is available and validated, the team can create the metrics needed to support the use cases.

Calculated insights aggregate or derive information from modeled data. They can help translate large volumes of customer and transaction records into business-relevant measures.

Examples include:

• Total customer spending.
• Number of purchases within a defined period.
• Most recent transaction date.
• Customer lifetime value.
• Number of service interactions.
• Recent engagement activity.

Consider a marketing team that wants to identify customers who have purchased frequently but have not engaged with recent campaigns.

The team may need a calculated metric for purchase frequency and a separate measure of recent campaign engagement. Those values can then support audience criteria or business analysis.

Not every use case requires calculated insights, and not every metric requires a separate calculated insight object. The team should determine the simplest appropriate approach based on the business requirements and the available data model.

Validate the calculations

Confirm that the metrics use the intended records, time periods, aggregation logic, and business definitions.

For example, two departments might define an active customer differently. One may use a purchase within the past 12 months, while another may use any interaction within the past six months.

These definitions should be agreed upon before the metrics are used in production decisions.

Checkpoint: Required calculated insights and other derived metrics have been validated against known examples or independently verified results.

Step 7: Build and Validate Segments

Segmentation uses modeled data and, where appropriate, unified profiles and calculated insights to group records according to defined criteria.

Segments translate the data foundation into audiences or groups that can support a business action.

For example, a marketing team might want to identify:

• Customers who purchased within the last 90 days.
• Customers who have not engaged with a campaign recently.
• High-value customers who qualify for a loyalty offer.
• Customers who purchased a particular product but have not purchased a related product.
• Customers whose service interactions indicate a potential retention opportunity.

The criteria should reflect the original business requirements and use the appropriate data objects, relationships, and metrics.

Why segmentation comes after data validation

A segment can be configured successfully and still produce the wrong audience if its underlying data is incomplete or its criteria are incorrect.

Before activating a segment, check the population it returns.

Do the record counts make sense? Are the expected customers included? Are ineligible customers excluded? Do the criteria reflect the intended business definition?

It is also important to determine whether the segment should operate on individual records, unified individuals, accounts, or another appropriate data model object.

The right choice depends on the use case and how the data will be consumed.

Checkpoint: The segment returns the intended audience, and its membership has been validated before downstream activation.

Step 8: Configure Activation and Connect the Data to Business Processes

Data 360 delivers business value when its data and insights can be used by the systems and teams that need them.

Activation publishes a segment or selected data to a supported target so that another system or process can use it.

Depending on the use case, activation targets may include marketing platforms, Salesforce applications, external platforms, or other supported destinations.

For example, a validated customer segment might be activated for use in a marketing campaign. The campaign can then be designed around the customer’s relevant attributes and eligibility criteria.

Other use cases may involve making insights available to sales or service teams, supporting automation, or providing context for AI-powered experiences.

Plan activation before the final implementation stages

Although activation comes after the relevant data foundation is established, activation requirements should be considered much earlier in the project.

The intended destination can influence which attributes need to be mapped, how records should be identified, which consent requirements apply, and what data must be included.

For that reason, teams should identify the destination during requirements gathering and validate the complete data path before launching the solution.

Test the end-to-end process

Before production use, confirm that:

• The correct segment or data is being published.
• Required attributes are included.
• Record identifiers and contact points are configured appropriately.
• Consent and eligibility rules are respected.
• The destination receives and processes the data as expected.
• The resulting campaign or business process behaves as intended.

Checkpoint: The intended audience or data reaches the target successfully and supports the business outcome for which it was designed.

Step 9: Monitor, Measure, and Optimize

Implementation does not end when the first segment is activated.

Data sources change, business requirements evolve, and new use cases emerge. Ongoing monitoring helps ensure that the solution continues to deliver reliable results.

Establish a process for monitoring ingestion, data quality, identity resolution, calculated insights, segment membership, and activation outcomes, as relevant to the implementation.

Business stakeholders should also review whether the original objectives are being achieved.

For example, if the goal was to improve campaign targeting, the team might compare audience quality, engagement, conversion rates, or other relevant measures against an established baseline.

If the goal was to improve customer service, measures might include the availability of relevant customer context, reduced manual research, or improvements in selected service outcomes.

Use these findings to prioritize improvements to the data foundation, business rules, and downstream experiences.

Checkpoint: Ownership, monitoring, issue resolution, and ongoing performance measurement are established.

Final Thoughts: Build the Foundation Before Scaling

A successful Salesforce Data 360 implementation is not about configuring every feature as quickly as possible. It is about establishing a reliable data foundation that supports specific business outcomes.

By defining the use cases first, understanding the source data, validating ingestion and mapping, configuring identity resolution where needed, and testing insights, segments, and activations, teams can reduce avoidable rework and build confidence in the results.

The most effective implementations also recognize that sequencing and validation go hand in hand. Each stage should produce an outcome that the team can verify before relying on it downstream.

Start with one well-defined business use case, establish the data foundation it requires, and expand from there. This approach creates a more manageable implementation and a clearer path from connected data to measurable business value.