Data Cloud is a separate data platform bolted onto your org, not a set of custom objects. It ingests data from many systems, maps it into a shared model, works out which records across those systems describe the same person or company, and makes the result available for segmentation, analytics and grounding AI. If your problem is joining two Salesforce objects, you do not need it. If your problem is that the same customer exists in six systems with five spellings, it is doing something nothing else on the platform does.
The pieces, in the order you meet them
Data streams bring data in. Connectors exist for Salesforce CRM, Marketing Cloud, cloud storage such as S3, an Ingestion API for streaming or bulk loads from your own systems, and zero-copy federation that queries a warehouse in place without moving anything. Each stream lands raw data in a data lake object.
Data model objects are the harmonised layer. You map fields from each data lake object onto a shared canonical model, so that a customer email from Marketing Cloud and one from an S3 export end up in the same field of the same entity. This mapping work is the bulk of a Data Cloud implementation, and it is unglamorous.
Identity resolution is the part that justifies the platform. You define match rules, which say what counts as the same individual, and reconciliation rules, which say which source wins when the matched records disagree. The output is a unified profile, and every downstream feature works from it rather than from any single source.
Calculated insights are aggregations defined once and computed on a schedule: lifetime value, order count, days since last purchase. Segments filter unified profiles. Activations push segments out to destinations. Data actions publish platform events when something crosses a threshold, which is how Data Cloud reaches back into the org.
Where the data actually lives
Not in standard objects. Not counting against your org’s file and data storage. It sits in Data Cloud’s own storage, queryable through a SQL query API, explorable in the Data Explorer, and surfaceable in the org through related list components and a handful of integration points.
That separation is the thing to internalise. Sharing rules, field-level security, Apex triggers and reports do not apply to data model objects the way they apply to Accounts. You are administering a second platform with its own permission model.
Identity resolution is a policy question
Match rules look technical and are not. Matching on exact email is safe and misses people. Matching on fuzzy name plus postcode catches more and will eventually merge two different people who live at the same address and share a surname.
Decide deliberately which errors you would rather make. For marketing segmentation, over-merging is annoying. For anything touching service history, billing or consent, over-merging is a data protection incident. Start strict, measure how many profiles are resolving, and loosen with evidence rather than optimism.
Reconciliation deserves the same care. “Most recently updated wins” sounds neutral and quietly lets whichever system writes most often become the source of truth for everything.
The honest cost question
Data Cloud is consumption-priced in credits. Ingesting rows consumes credits. Processing them consumes credits. Segmentation runs, calculated insights, identity resolution jobs, activations and API queries all consume credits, at different rates. Profile storage is billed separately.
The practical consequence is that the cost is driven by your design, not by your data volume alone. A stream configured as a full refresh of a large object every night costs dramatically more than the same object ingested incrementally. A calculated insight over all history recomputed hourly costs more than one that recomputes daily. Teams routinely get a bill several times what they projected, and the cause is almost always refresh frequency rather than row count.
Some editions now include a starter allocation of credits, enough to build something real and not enough to run it at production scale. Treat that as a pilot budget. Model the credit consumption of your intended design before committing, and build in incremental ingestion from the start.
Frequently asked
Do I need Data Cloud for Agentforce? Not for actions over standard objects. You need it when an agent must be grounded in unstructured content or in data that does not live in the org.
Can I write back to CRM objects? Through data actions publishing platform events, and through specific features that surface insights onto records. It is not a general-purpose write-back sync.
How long does an implementation take? The connectors are quick. Mapping and identity resolution are where the months go, because they are data governance decisions wearing configuration screens.
