It is now the foundation Agentforce, Marketing Cloud Next and Einstein all run on — and it is consumption-priced, so every ingestion, refresh and activation is metered. We design across all three Cs: Consistency, Connectivity and Cost.
Trusted by 500+ organizations — including RevOps, marketing operations and data teams building their customer data foundation on Salesforce with Twopir Consulting.
Built for Activation
Every one of these is a design decision made early and discovered late. None of them is fixed cheaply after the fact, which is why the architecture work happens before any configuration.
Teams that model Data 360 like a warehouse end up with bloated profiles, slow queries and downstream platforms that cannot use what they need. Schema design for activation is a different discipline, and most first attempts get it wrong.
Streaming everything in real time feels right until the invoice lands. Teams that did not design for cost end up throttling activations, disabling segments or rearchitecting mid-flight — all of which costs more than getting it right first.
Matching too strictly misses real connections across systems; matching too loosely merges people who are not the same person. Without testing against real data, the unified profile is neither unified nor a profile — it is noise at scale.
Data 360 is the layer AI is grounded on. If the profile is incomplete, stale or poorly modelled, the outputs reflect that — and a confident wrong answer is worse than no answer, however sophisticated the AI layer above it.
Teams choose zero-copy to avoid Data 360 storage charges and are surprised when the Snowflake or Databricks bill rises instead. Zero-copy moves compute cost to the connected platform — an architecture built without understanding that rarely stays in budget.
Data 360 rewards a crawl-walk-run sequence: one use case, then several segments, then scale once the return is understood. Programmes that connect every source on day one spend heavily before they know which data actually moves a number.
Salesforce Data 360 unifies customer data from CRM, marketing, service, commerce and external systems into a single real-time profile. It is the data layer that Agentforce, Marketing Cloud Next and Einstein are grounded on — which means that for a growing number of organisations, adopting any of those products means operating within Data 360 whether or not it was a separate decision.
The distinction that trips up most teams: the unified profile is not a golden record. A golden record in traditional master data management implies one cleaned, verified source of truth written back to the originating systems. Data 360 assembles a dynamic, real-time profile by merging data from multiple sources without altering the originals. It is built for activation — personalisation, AI grounding, segmentation — rather than for governance in the MDM sense. Model it as though it were a warehouse and you get something that is expensive to run and hard to activate against.
What Salesforce ships is a platform. What decides whether it performs is the schema, the identity rules and the ingestion design underneath — which is the work Twopir Consulting is engaged to do. It is the layer beneath our Agentforce and Marketing Cloud practices, and it sits inside the wider Salesforce services we deliver.
Consistency, Connectivity and Cost. All three have to be settled before configuration starts — each one is cheap to decide early and expensive to revisit once data is flowing.
Data modelling is everything
The promise is a unified profile — one real-time truth set across every system. How you model it decides whether that promise holds. Unification is a dynamic representation built for activation, not a governed master record.
Mistakes here ripple outward into Agentforce, Marketing Cloud Next and every downstream platform — and each one has to be re-tested when you eventually fix the model.
Real-time is not always the right time
Data 360 supports streaming, batch, API and zero-copy. Each has a different cost and latency profile. The question is not just how you connect a source but why — what business decision actually requires this data to be fresh?
You end up paying real-time prices for data nobody acts on in real time — the single most common source of avoidable spend in a Data 360 build.
Every interaction has a price
Data 360 is consumption-based, not flat-rate. Ingestion, transformation, segment refresh and activation are all metered. This is where elegant architectures go off the rails, and why the crawl-walk-run sequence is not optional.
Cost governance cannot be retrofitted usefully — by the time the trend is visible on a dashboard, the ingestion and refresh decisions driving it are already load-bearing.
Most Data 360 bills are decided here, source by source. The right answer is usually a mix — and picking per source, against a real business need for freshness, is most of the cost control there is.
| Criteria | Real-time streaming | Batch ingestion | Zero-copy |
|---|---|---|---|
| Data freshness | Seconds. The profile reflects what someone is doing right now. | Scheduled. Minutes to hours old, depending on cadence. | Live at query time, read from the source platform. |
| Where cost lands | In Data 360, per event ingested — volume adds up quickly. | In Data 360, but far less per record than streaming. | On the connected platform. Storage is avoided; compute is not. |
| Best for | Personalisation, journey triggers and agent context that must be current. | Transactional history, reference data, anything not decision-critical by the minute. | Large warehouse datasets you want to activate against without duplicating. |
| Watch out for | Streaming sources nobody acts on in real time — the classic avoidable spend. | Latency quietly breaking a use case that assumed freshness. | Runaway compute on Snowflake or Databricks, which shows on a different bill. |
| Governance needed | Event volume monitoring and a defined reason for each stream. | Refresh cadence reviewed against how the data is actually used. | Query governance on the source platform, agreed with whoever owns it. |
Three genuinely different jobs. On this product the middle one is often urgent — teams call when consumption is climbing faster than the value they can point to.
For teams standing up Data 360 for the first time
A first build, scoped deliberately small. We design the data model, identity rules and ingestion plan against one activation use case, prove it, and expand from evidence rather than connecting every source on day one.
Delivered with configuration and standard connectors. Custom ingestion, bespoke transformation and API development are scoped separately — and we will say plainly when a source is not worth connecting yet.
For teams whose consumption is outrunning the value
The architecture works and the bill is climbing, or the profile is not trusted and nobody can say why. We instrument consumption, find where spend and value have separated, and correct the decisions driving it.
Tuning cannot rescue a schema modelled for reporting. Where the data model itself cannot support activation, we say so and scope the remodel honestly rather than trimming refresh schedules around a structural problem.
For teams past the first use case
Custom work for what standard connectors and configuration cannot reach: bespoke ingestion, complex calculated insights, zero-copy architectures with governance, and the grounding design that AI on top of this layer depends on.
Every custom pipeline is something you own and pay to run. Each one is justified against a named activation use case before it is built — if it does not feed a decision, it does not get connected.
Each capability is designed against a named activation use case, with a cost expectation attached — not switched on because the platform offers it.
Source fields mapped to the standard objects — Individual, ContactPoint, Engagement — with custom objects only where the business genuinely needs them, designed so downstream platforms can activate against it.
Deterministic and probabilistic matching rules that link the same person across CRM, commerce, marketing and external systems — tuned against your real records, not clean synthetic ones.
Streaming, batch, API and zero-copy chosen per source against a real freshness requirement — with the cost consequence of each decision made explicit before it is built.
Audiences built from unified profile data and pushed to the platforms that use them, with refresh cadence set deliberately — because refresh frequency is a cost decision as much as a freshness one.
The profile shaped specifically for what agents need to answer well. Grounding quality is usually what caps agent usefulness, and it is a data modelling problem long before it is a prompt problem.
Designed into the architecture rather than bolted on as a dashboard. Ingestion modes, refresh cadences and activation rules are the levers, and they are set while they are still cheap to change.
A focused engagement typically runs 8–16 weeks, depending on how many sources are connected, how complex identity resolution is, which activation targets are in scope, and whether historical data needs remediation first.
We audit the landscape — which clouds you run, which external sources matter, where identity is fragmented today, and which downstream use cases will consume the profile. The output is an architecture decision record: what gets ingested, what stays zero-copy, which mode applies to which source, and a twelve-month cost model.
Source fields mapped to the standard model, identity resolution rules defined against your actual records rather than synthetic ones, and survivorship logic settled for conflicting attributes. This is the phase most implementations rush and most regret, so we treat it as a quality gate before anything reaches production.
Ingestion built per source with cost governance in each connection, then segments, calculated insights and activation targets configured and tested against real profile data. Agentforce grounding and marketing integrations are validated end to end before cut-over, not after.
We document the architecture, stand up cost monitoring, and run enablement for your admins and operations team. You get a crawl-walk-run roadmap naming which use cases to expand into next and which checkpoints to clear first. You own the architecture — it is built to be operated without us.
Deliberately stated as outcomes rather than percentages. We have not attached numbers to these because we cannot source them to a specific engagement — and an invented figure would be worth less to you than an honest description.
When the profile is properly modelled, agents have the context to answer accurately instead of assembling something from disconnected CRM fields. The difference shows up in resolution rates and in how quickly people stop double-checking the agent.
Segments built on unified profiles — behavioural, transactional and engagement data together — behave differently from segments built on CRM fields alone. Personalisation reflects what someone actually did, not what was last typed into a contact record.
Sales, service, marketing and commerce see the same customer, unified across touchpoints and current — with no reconciliation ritual before a meeting or a send.
An architecture designed with cost governance from the start does not surprise you at renewal. Monitoring, refresh schedules and activation governance mean usage scales because you decided to, not because something drifted.
Lifetime value, churn probability and engagement scores computed natively on the unified profile stay live. Teams work from current numbers rather than a quarterly model refresh that was stale before it shipped.
Because Data 360 sits under most of what Salesforce ships next, a well-designed implementation scales forward. New Agentforce capability and new marketing features connect to a profile that is already production-grade.
Illustrative scenarios rather than client case studies. If one of these describes your quarter, the first call will be specific rather than a platform overview.
Agents deployed on fragmented CRM data produce confident, incorrect output. The fix is underneath them: unified profiles, identity resolution and ingestion from the sources agents actually need. See our Agentforce practice.
Marketing Cloud Next runs on this layer, and a data model built around subscriber lists and contact records does not translate to unified profiles and event-based activation. We map the migration and rebuild the model for the new paradigm. See our Marketing Cloud practice.
Running Sales, Service and Commerce and finding one customer with three names, three histories and three sets of records. Unification resolves identity across all three and produces a single timeline available to agents and automation without manual reconciliation.
Significant data already in Snowflake or Databricks, and no appetite to pay to duplicate it. Zero-copy lets Data 360 query it in place — and we design the source-side governance that keeps the compute bill from replacing the storage bill.
Data 360 punishes decisions made in the wrong order more than any other product in the Salesforce estate, because the expensive ones are invisible until data is already flowing.
Identity fragmentation, source inventory, downstream use cases and a twelve-month consumption projection come before configuration. Generic setups built on assumptions produce generic results and unpredictable bills.
Matching that passes on clean test data fails on real records full of abbreviations, transliterations and source-system artefacts. We validate against a representative production sample before a single production profile is processed.
Ingestion modes, refresh cadences and activation rules are the levers that control spend, and they are architecture decisions. Teams we work with have been watching the trend since week one rather than discovering it at renewal.
This is the foundation for Agentforce, Marketing Cloud Next and Einstein. We implement it with those consumers in mind rather than as a standalone data project, because the schema decisions here determine how well everything above performs.
Twopir Consulting has delivered Salesforce for 12+ years across multi-cloud implementations, post-acquisition org merges and orgs where data has not been governed in years. The patterns are familiar; the configuration is yours.
Yes — same product, renamed. Salesforce renamed Data Cloud to Data 360 in October 2025 as part of moving its portfolio under the Agentforce 360 umbrella. It is the same licence, the same data model and the same segmentation tools; several capability layers shipped alongside the rename rather than replacing anything. Expect a mixed picture for some time: pricing and product pages lead with Data 360, while much of Salesforce's documentation, Trailhead content and certification material still says Data Cloud, and most practitioners still search for it under the old name. If you are comparing partners, treat "Data Cloud experience" as current experience — it is the same platform.
No, and the distinction matters architecturally. A golden record in traditional master data management implies a single cleaned and verified source of truth that is written back to the originating systems. Data 360 unification creates a dynamic, real-time profile that merges data from multiple sources without altering the originals. The unified profile is built for activation — powering personalisation, AI grounding and segmentation — not for governance in the MDM sense. Teams that model it as though it were an MDM hub or a data warehouse end up with bloated profiles, slow queries and downstream platforms that cannot use what they need.
Consistency, Connectivity and Cost. Consistency is how you model and unify data — schema design, identity resolution rules and survivorship logic. Connectivity is how and when you connect each source: real-time streaming, batch ingestion, API, or zero-copy queries against platforms like Snowflake. Cost is the consumption-based pricing model, where ingestion, transformation, segment refresh and activation are each metered. All three have to be settled before configuration starts, because each is cheap to decide early and expensive to revisit once data is flowing and downstream platforms depend on it.
Data 360 is consumption-priced rather than flat-rate, so you pay for data rows ingested, profiles unified, segments refreshed and activations triggered — and sending data onward to other platforms carries its own cost. The largest avoidable expense we see is streaming sources that nobody acts on in real time. The question worth asking of every source is simple: what business decision changes if this data is an hour old? If the answer is none, it does not need streaming. Beyond that, predictability comes from deciding ingestion modes, refresh cadences and activation rules during architecture rather than after, and from a crawl-walk-run sequence — one use case, then several segments, then scale once the return is understood. Cost governance cannot be usefully retrofitted, because by the time a trend is visible on a dashboard the decisions driving it are already load-bearing.
Zero-copy lets Data 360 query data held in external platforms — Snowflake, Databricks, BigQuery — without physically ingesting and storing it. That avoids ingestion and storage cost inside Data 360, which makes it well suited to large datasets you want to activate against but do not want to duplicate. The trade-off people miss is that zero-copy moves cost rather than removing it: the compute charge lands on the connected platform instead, and it shows up on a different bill owned by a different team. We decide per source which should be ingested and which should stay zero-copy, based on the actual activation use case and a cost projection covering both sides — and we design the source-side query governance that stops the compute bill simply replacing the storage bill.
It provides the unified profile that grounds agents. When an agent needs to understand a customer's history, preferences or current context, it draws on the real-time profile assembled here rather than isolated CRM fields — so the quality of this implementation sets a ceiling on how useful any agent above it can be. Two practical consequences. First, when agents give incomplete or conflicting answers, the cause is usually a grounding gap rather than a prompt problem, and rewriting prompts will not fix it. Second, agents grounded on Data 360 consume Data 360 credits from a pool separate to Agentforce consumption, so a grounded agent costs more to run than the headline Agentforce figure suggests. Both pools should be modelled together before you commit to a design.
A focused engagement typically runs 8 to 16 weeks. What moves that range is the number of source systems being connected, how complex identity resolution needs to be, which downstream activation targets are in scope — Agentforce, Marketing Cloud Next, external platforms — and whether historical data needs remediation before it is worth ingesting. We start with a data architecture assessment in week one and finish with a production-ready configuration, documentation and enablement, so your team can operate it without depending on us. The sequencing advice we give almost everyone is to keep the first phase narrow: one activation use case proven properly is a better foundation than six sources connected on the assumption they will all be needed.
We map your current data landscape, find the gaps in the unified profile, and show you what a well-implemented Data 360 would unlock — with a cost model attached, so the decision is made on numbers rather than on enthusiasm.
Response within 24 hours · We start with diagnosis, not a sales call · Contact the team
