Customer Data Platforms Guide | SalesforceTutorial

What are customer data platforms?

Customer data platforms are systems that ingest customer-related data from several sources, standardize it, connect matching identities, and make the result available for action. In Salesforce projects, the action may be a Marketing Cloud audience, a Commerce experience, a Service Cloud related list, a Tableau analysis, a Flow automation, or an Agentforce grounding pattern.

A CDP is not just a database. It includes ingestion, data modeling, identity resolution, consent handling, segmentation, activation, and operational monitoring. The value comes from the relationships between these parts. A segment built on unmapped, duplicated, or unconsented data creates risk even if the campaign tool can technically send the message.

Salesforce Help describes Data 360 as the product that harmonizes data to a standard model, unifies data with identity resolution rulesets, queries and analyzes data using insights, and uses AI to predict behavior. For the current Salesforce product overview, see Salesforce Help: About Salesforce Data 360.

When should Salesforce teams use customer data platforms?

Use customer data platforms when a team needs profile decisions that no single Salesforce cloud or external system can make alone. If Sales Cloud, Service Cloud, Marketing Cloud, Commerce, and the warehouse each hold part of the customer story, customer data platforms give architects a controlled place to connect those signals.

• Use customer data platforms when campaign eligibility depends on purchases, cases, consent, and engagement history together.
• Use customer data platforms when identity resolution is needed before marketers can trust audience counts.
• Use customer data platforms when the same customer appears as a lead, contact, loyalty member, and ecommerce buyer.
• Use customer data platforms when activation needs suppression rules that come from service or compliance systems.
• Avoid customer data platforms for a single-source email list where Marketing Cloud data extensions already meet the requirement.

How do customer data platforms map to Salesforce Data 360?

The term salesforce cdp usually refers to the same product family now called Data 360. Salesforce has changed the branding over time, so admins may see names such as Customer 360 Audiences, Salesforce CDP, Marketing Cloud Customer Data Platform, Data Cloud, and Data 360 in documentation, older implementation notes, or screenshots.

As of October 14, 2025, Salesforce Help says Data Cloud was rebranded to Data 360. That matters because current navigation, permissions, and Help articles may use Data 360 even when a stakeholder asks for a salesforce cdp implementation.

Salesforce cdp architecture in one flow

1. Connect source systems. Bring in CRM, service, commerce, marketing, web, mobile, data warehouse, and consent data through supported connectors or APIs.
2. Create data streams. Each data stream controls how source data arrives in Data 360 and how it becomes available for mapping.
3. Map DLOs to DMOs. Raw source fields land in DLOs and are mapped into the Customer 360 data model or custom DMOs.
4. Run identity resolution. Rulesets create unified profiles from source profile data when matching and reconciliation rules meet your business rules.
5. Build insights and segments. Marketers and analysts use attributes, relationships, and calculated insights to define audiences.
6. Activate governed data. Segments publish to destinations such as Marketing Cloud or other activation targets, depending on licensing and setup.

For a broader site-level tutorial, connect this article with our Salesforce Data Cloud implementation guide and Agentforce Salesforce implementation notes.

How does marketing cloud cdp fit into Salesforce?

Marketing cloud cdp is a common search phrase for using Data 360 with Salesforce marketing products. The business goal is usually to create audience segments from data that lives outside the email platform: purchase history, loyalty tier, service cases, product browsing, mobile app events, or consent status.

Marketing Cloud Engagement can store subscribers and engagement data, but a CDP project asks a wider question: which people should be included, excluded, suppressed, or moved into a journey after all known customer signals are considered? That is where customer data platforms help marketing teams avoid narrow decisions based on one channel.

Marketing cloud cdp data sources to review

• Subscriber and contact identifiers: SubscriberKey, ContactKey, CRM Contact ID, Lead ID, external customer ID, loyalty ID, or hashed email.
• Engagement data: sends, opens, clicks, form submissions, SMS interactions, push activity, journey membership, and preference changes.
• Commerce and order data: products, categories, abandoned carts, returns, lifetime value, and purchase frequency.
• Service data: open cases, recent complaints, escalations, warranty claims, and satisfaction signals.
• Consent and preference data: data use purpose, communication subscription status, region, channel consent, and lawful basis where required.

In enterprise orgs, a marketing cloud cdp build fails when Marketing owns the segment but no one owns the customer identifier strategy. Decide the identifier hierarchy before building journeys. For example, if Email A belongs to a consumer profile and the same person has a B2B Contact record, the identity rules must define whether those records unify, stay separate, or unify only after another identifier confirms the match.

What does customer 360 cdp mean in Salesforce architecture?

Customer 360 cdp is best understood as an architecture pattern: use Salesforce’s customer data model and identity tools to create a governed view of a person, account, household, or business relationship. It does not mean every system must copy every field into one table.

Salesforce Data 360 uses DLOs and DMOs to separate raw ingestion from harmonized business entities. Salesforce Developer documentation explains that DMOs organize and harmonize data in Data 360, and query documentation shows standard DMO examples such as Individual and Contact Point Email. This separation helps architects control where source data lands, what becomes part of the common model, and what downstream tools can query.

Customer 360 cdp design decisions

How is a cdp in marketing used without breaking trust?

A cdp in marketing should improve audience decisions without ignoring consent, channel fatigue, or service context. The common mistake is to treat the CDP as a bigger email list. The better pattern is to use customer data platforms to decide who qualifies, who must be excluded, and which message should wait.

Cdp in marketing examples for Salesforce teams

For related marketing platform concepts, review our Salesforce Marketing Cloud tutorial and Salesforce Pardot and marketing automation article.

Customer data platforms readiness checklist

Before buying or expanding Data 360, use this checklist to confirm that customer data platforms will solve a defined problem rather than create another data store.

• Customer data platforms need named source-system owners for CRM, marketing, commerce, service, and warehouse data.
• Customer data platforms need a documented identity strategy with primary keys, fallback keys, and match confidence rules.
• Customer data platforms need consent and suppression fields that marketers can understand before activation.
• Customer data platforms need segment acceptance criteria, including expected counts and test customer records.
• Customer data platforms need monitoring for data streams, identity jobs, calculated insights, and activation runs.
• Customer data platforms need a release process for changes to mappings, rulesets, segments, and activation targets.
• Customer data platforms need cost controls because ingestion, processing, query, and activation patterns can affect consumption.
• Customer data platforms need rollback plans when a source field changes, a connector fails, or a segment publishes incorrect members.

How to implement customer data platforms in Salesforce

Implementation should start with one measurable use case. Do not begin with a request to connect every source. Start with one segment, one activation target, and one accountable business owner. Then expand the data model after the first use case proves that the identifiers, consent rules, and refresh timing work.

Step 1: define the business action

Write the action in operational language: “send this audience to Marketing Cloud every morning,” “show the unified profile to service agents,” or “trigger a webhook when a calculated insight changes.” If the action is unclear, the data model will grow without a testable outcome.

Step 2: audit identifiers and consent

List every field that can identify a person or account. Include CRM ID, ContactKey, email, phone, loyalty ID, device ID, external account ID, and warehouse customer ID. Then document which consent field controls each activation. For regulated industries, involve privacy and legal teams before segment activation, not after the build.

Step 3: set up users and data spaces

Assign Data 360 standard permission sets based on job responsibility, not convenience. Admin users need setup access; marketers need segmentation and activation access; developers need API and metadata access. Data spaces can separate data for different brands, regions, or business units when governance requires partitioning.

Step 4: ingest and map source data

Use connectors where available. Use Ingestion API when an external system must push files or micro-batches into Data 360. Salesforce Developer documentation states that Ingestion API supports bulk and streaming interaction patterns; review Salesforce Developers: Ingestion API before designing the integration.

Step 5: build identity rulesets with test data

Identity resolution creates unified profiles from source profile data stored in Data 360. Test with records that represent real problems: shared household email, recycled phone number, B2B contact with a personal email, duplicate loyalty account, and region-specific consent. A ruleset that works only with clean demo data will not survive production.

Step 6: create segments and compare counts

Marketers should validate segment counts against expected source-system counts before activation. A sudden mismatch usually points to missing DMO relationships, incorrect date fields, unhandled nulls, late data stream refreshes, or identity rules that changed the number of unified profiles.

Step 7: activate and monitor

Activation publishes segment membership to a destination so teams can act on it. Track activation refreshes, destination failures, field-level requirements, and suppression logic. Add runbook entries for common failures so support teams know whether to fix source data, identity rules, segment logic, or the activation target.

Developer examples for salesforce cdp and Data 360

Developers usually help with ingestion, query, automation, and operational monitoring. Use the API that matches the job. Salesforce Developer documentation lists Connect REST API for platform-integrated apps, Connect API in Apex for a subset of Data 360 resources, Data 360 API for direct tenant access, SOQL for certain Data 360 objects, and Metadata API for selected metadata movement. The Connect API reference is available at Salesforce Data 360 Connect REST API.

Ingestion API streaming example with retry handling

The exact object endpoint comes from the configured Ingestion API connector in your Data 360 org. The example below keeps the endpoint externalized and shows the guardrails that matter in production: payload size, bearer token handling, 202 response handling, and 429 backoff.

/**
 * Send a small micro-batch to a Data 360 Ingestion API object endpoint.
 * Requirements:
 * - The endpoint URL is copied from the Ingestion API connector details.
 * - The JSON fields match the source object schema in the data stream.
 * - The request body stays below the Salesforce streaming ingestion payload limit.
 */
async function sendData360MicroBatch({ objectEndpointUrl, data360AccessToken, records }) {
  if (!objectEndpointUrl || !data360AccessToken) {
    throw new Error('Missing endpoint URL or Data 360 access token.');
  }

  const payload = {
    data: records.map((record) => ({
      CustomerId: String(record.customerId),
      EmailAddress: record.emailAddress || null,
      LastPurchaseDate: record.lastPurchaseDate || null,
      ConsentStatus: record.consentStatus || 'Unknown'
    }))
  };

  const response = await fetch(objectEndpointUrl, {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${data360AccessToken}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(payload)
  });

  if (response.status === 202) {
    return { accepted: true };
  }

  if (response.status === 429) {
    throw new Error('Data 360 ingestion rate limit reached. Retry with exponential backoff.');
  }

  const errorText = await response.text();
  throw new Error(`Data 360 ingestion failed: ${response.status} ${errorText}`);
}

Production note: do not log access tokens or raw personal data. Log connector name, object name, correlation ID, record counts, and error category instead. Salesforce lists 202 Accepted as the successful processing response for streaming ingestion and documents rate-limit handling for 429 responses.

Data 360 SQL query example for unified profile review

Use Data Explorer or Query APIs to test whether the model returns the attributes marketers expect. The following ANSI SQL pattern joins individual and email data using DMO names shown in Salesforce query documentation. Check your org’s object API names because names can differ between standard, legacy, custom, and packaged models.

SELECT
  i.ssot__Id__c AS individual_id,
  i.ssot__FirstName__c AS first_name,
  i.ssot__LastName__c AS last_name,
  e.ssot__EmailAddress__c AS email_address
FROM ssot__Individual__dlm AS i
INNER JOIN ssot__ContactPointEmail__dlm AS e
  ON i.ssot__Id__c = e.ssot__PartyId__c
WHERE e.ssot__EmailAddress__c IS NOT NULL
LIMIT 100;

Use this style of query during testing, not as a substitute for identity resolution. Query results show whether objects and relationships behave as expected; identity resolution rulesets decide how source profiles become unified profiles.

Apex callout pattern for operational alerts

Keep Data 360 ingestion outside triggers. If Salesforce Platform activity needs to notify an external integration layer, publish a Platform Event or enqueue a callout job. The Queueable example below is a safe pattern for sending a small operational message to middleware; the middleware can then call Data 360 using the correct OAuth exchange and endpoint details.

public with sharing class CdpIntegrationAlertJob
    implements Queueable, Database.AllowsCallouts {

    private final Id sourceRecordId;
    private final String eventType;

    public CdpIntegrationAlertJob(Id sourceRecordId, String eventType) {
        this.sourceRecordId = sourceRecordId;
        this.eventType = eventType;
    }

    public void execute(QueueableContext context) {
        if (sourceRecordId == null || String.isBlank(eventType)) {
            return;
        }

        HttpRequest request = new HttpRequest();
        request.setEndpoint('callout:CustomerDataMiddleware/events');
        request.setMethod('POST');
        request.setHeader('Content-Type', 'application/json');

        Map<String, Object> body = new Map<String, Object>{
            'sourceRecordId' => String.valueOf(sourceRecordId),
            'eventType' => eventType,
            'source' => 'Salesforce'
        };
        request.setBody(JSON.serialize(body));

        HttpResponse response = new Http().send(request);
        if (response.getStatusCode() >= 400) {
            throw new CalloutException(
                'Middleware callout failed with HTTP ' + response.getStatusCode()
            );
        }
    }
}

Governor limit note: enqueue this job after the triggering transaction decides that a notification is needed. Do not run one callout per record inside a loop. Bulk-trigger logic should collect affected record IDs, apply business rules once, and enqueue the minimum number of async jobs required.

Best practices for Data 360 security and governance

Customer data platforms concentrate data from many systems, so governance cannot be an afterthought. In Salesforce, align Data 360 access with the principle of least privilege. Permission sets, data spaces, activation target access, and source-system controls should all support the same governance model.

• Use named integration users. Avoid shared admin credentials for ingestion or activation jobs.
• Separate setup and marketing duties. The person who maps data should not automatically have permission to activate every segment.
• Document consent lineage. A segment should make it clear which consent object or field allowed the action.
• Monitor usage and limits. Ingestion, identity processing, query, activation, and calculated insight runs can affect cost and performance.
• Review data retention. Confirm how long source data, unified profiles, and activated audiences should remain available.

Use our Salesforce reports and dashboard basics guide when planning monitoring views for refresh failures, campaign counts, and operational health.

Customer data platforms vs CRM, DMP, and data lake

Teams often confuse CDP work with systems they already own. The difference is not only storage. It is the combination of identity, consent, segmentation, and activation.

Common errors with customer data platforms

The technical work is manageable when the operating model is clear. Most failures come from unclear ownership, weak identifiers, or segment logic built before the data model is ready.

• Mapping fields without a use case: More fields increase governance and testing work. Map what the segment, insight, or profile view needs.
• Using email as the only identity key: Email changes, can be shared, and may not represent the legal or account relationship.
• Ignoring null behavior: Query joins and segment filters can drop records when key fields are null. Test missing values explicitly.
• Activating without suppression checks: A campaign can be technically correct and still wrong if an open complaint, opt-out, or region rule should suppress it.
• Skipping monitoring: Data streams, identity jobs, calculated insights, and activations all need operational owners.
• Confusing old names with new features: A request for marketing cloud cdp or customer 360 cdp may still mean Data 360, but licensing and UI labels must be checked in the current org.

Current Salesforce naming and release notes to check

Salesforce product names changed several times across the CDP product line. For 2026 content and implementation planning, use Data 360 as the current name and note that older search terms remain common. When writing requirements, include both the business term and the current Salesforce feature name. For example: “Build a win-back audience in Data 360 Segments,” not only “build a salesforce cdp campaign.”

Before build work begins, check three sources: Salesforce Help for admin setup, Salesforce Developer documentation for APIs and supported objects, and Trailhead for role-based learning. The Trailhead Data 360 trail is useful when admins, marketers, and developers need a shared vocabulary before workshops.

What should you do next with customer data platforms?

Start with one use case and write the data contract before configuration. Customer data platforms work best when the team knows the audience rule, source fields, consent source, activation target, and failure owner.

For Salesforce teams, customer data platforms should connect marketing cloud cdp requirements with salesforce cdp setup decisions. Customer data platforms should also document customer 360 cdp identity rules and cdp in marketing activation rules in the same project backlog.

Do not measure customer data platforms only by the number of sources connected. Measure whether customer data platforms produce segments that marketers can explain, admins can govern, developers can monitor, and customers can trust.

Frequently Asked Questions