Author: Saransh

Next Level #7: Cut segment credits with two hidden settings

Next Level #7 · Credits

You build a segment in Marketing Cloud Next. You pick the attributes, check the count, attach it to a campaign and move on.

What you probably didn’t touch: how far back it looks, and how often it runs.

Those two settings decide how much data every single run processes. And unlike a send, a segment keeps running long after the campaign has gone quiet.

So which settings should you check, and how do you cut segment credits without breaking your audiences?

So, let’s have a look.

Segment credits tip in a nutshell

Use case: a marketing team runs dozens of Data 360 segments behind Marketing Cloud Next campaigns and flows.
Challenge: each segment re-processes profiles and engagement data on every publish, sized by its lookback window and repeated by its publish schedule.
Best solution: right-size every segment: stop the unused ones, match the schedule to the send, and match the lookback to the audience logic.
Watch out for: a lookback that’s too narrow silently drops customers who should qualify.

The use case

Marketing Cloud Next segments are Data 360 segments. Every audience you target from a campaign or flow is evaluated in Data 360, and that evaluation is billed.

Most teams create segments quickly, often by copying an existing one, and segment credits are rarely part of that conversation. Months later the org has dozens of them, all publishing on a daily schedule with whatever lookback they were born with.

Nobody wants to be the person who explains to finance why credits spiked in a month with no new campaigns.

Example scenarios

A weekly newsletter audience that publishes every day, so six out of seven runs feed nothing.
A Black Friday segment with a 2-year lookback, still publishing every morning in March.

The challenge

“Segments are just filters. They don’t really cost anything until you send.”

Well… no. Salesforce’s credit consumption module lists Segmentation and Activation as usage types of their own. Credits are calculated as rows processed ÷ 1 million × a multiplier, every time the segment runs.

And the Trailhead unit on lookback and schedules names the two dials directly: “A wider lookback means more data to process. A more frequent schedule means more compute cycles per day.”

The lookback window: it controls how far back Data 360 reads event data (engagement, orders) when evaluating criteria, based on each record’s event timestamp. The default is 90 days, and it can go up to 2 years (or 360 days, depending on org settings).

The publish schedule: standard segments publish on a schedule (daily, weekly or monthly, with intervals such as 12 or 24 hours) or manually with Publish Now.

What it costs: Salesforce’s own marketing pricing example says a single segment scans “all of Evergreen’s unified profiles and relevant engagement data, processing approximately 3 million rows.” At that page’s segmentation multiplier of 20, that’s about 60 credits per run. Daily, that’s about 21,900 credits a year for one segment. The page’s 100 daily segments come to over 2 million credits a year.

On the newer Flex Credits rate card (31 August 2026), segmentation is 50 credits per million rows at the base tier, so the same run uses more credits until volume tiers kick in.

Who notices: usually nobody, until segment credits on the Digital Wallet consumption card look wrong.

One segment run processes profiles plus engagement data inside the lookback window, multiplied by runs per day

Possible solutions to cut segment credits

Option A: do nothing

Accept the default schedule and lookback and budget the segment credits that come with it. It’s simple, but you pay for every unused run, every day.

Option B: reduce the publish schedule

Match each segment’s schedule to how often it’s actually sent. It’s easy and the saving is predictable: a weekly send on a weekly schedule runs 52 times a year instead of 365.

Option C: narrow the lookback window

Set the lookback to the shortest window the audience logic genuinely needs. It cuts the engagement data processed on every run, but it needs care, because it changes who qualifies.

Option D: switch off unused segments

Salesforce’s own advice is to “deactivate projects that aren’t being used”, naming “outdated segments that are still running.” This one is pure saving, but it’s a one-off clean-up unless someone owns it.

Option E: pre-aggregate into a calculated insight

Calculate something like “last engaged date” once in a calculated insight, then segment on it. It can simplify segments, but calculated insights are billed too, and Salesforce doesn’t document how much segment processing this saves.

Option	Credits saved	Effort	Audience risk	Saving lasts?
A. Do nothing	None	None	None	—
B. Reduce schedule	High	Low	Low	Yes
C. Narrow lookback	Medium (undocumented)	Low	Medium	Yes
D. Stop unused	High	Low	None	Only if repeated
E. Calculated insight	Unclear	Medium	Low	Yes, with its own cost
B + C + D as an audit	Highest	Low	Managed	Yes

The best solution: a right-size audit for every segment

Combine the three cheap levers for segment credits into one checklist, and run it for every new segment and once a quarter for existing ones.

Is it still used? Check which active campaigns and flows reference the segment. If none do, stop its schedule. Keep the definition if you might reuse it.
Match the schedule to the send. Weekly sends get weekly schedules. For one-off campaigns, publish manually shortly before the send. The data lags unit says records are typically available 15–30 minutes after a publish completes.
Match the lookback to the audience logic. Salesforce’s guidance is 7 or 30 days for a flash sale, 90 days for recent activity, and 6 or 12 months for win-back. Where only one criterion needs a short window, narrow it on that container: a container’s narrower range takes precedence for that criterion.
Check the count before and after. Note the segment population before the change. If it drops more than you expected, the lookback is cutting out real customers.
Measure it. Compare segment credits (the Segmentation line in Digital Wallet) for the month before and after.

Where: the segment’s publish settings for the schedule. The lookback is set when you create the segment.

Runs: at creation, then quarterly. Put it on the campaign calendar so it isn’t left to memory.

A four-question audit: is the segment used, how often is it sent, how far back does it need to look, and did the count change

Why this is the best solution

It uses the levers Salesforce names. Lookback and schedule are the two settings the documentation explicitly ties to consumption.

Every future run uses fewer segment credits. A narrower lookback or a lighter schedule reduces every run that follows, not just one.

No build required. These are settings, not a data model change, so a marketer can make them in an afternoon.

It’s reversible. If a count looks wrong, you widen the window or restore the schedule.

If a client asked me tomorrow, I’d start with step 1. In most orgs the cheapest segment run is the one that shouldn’t be happening at all. I’d only reach for calculated insights once the audit is done and a few heavy segments remain.

Considerations and limitations

Audience accuracy: the lookback only reads records whose event timestamp falls inside the window. Too narrow, and lapsed-but-valuable customers quietly vanish.
Rapid segments are different: lookback applies only to standard publish. Rapid segments (1- or 4-hour refresh) always use the past 7 days of engagement data, and you can’t switch a segment from standard to rapid after creation.
Activation is a separate bill: a scheduled segment must also activate to a target, which is billed as Activation. The first publish to a target is always a full refresh.
Profiles still count: as I read Salesforce’s pricing example, a run scans unified profiles and engagement data. A narrower lookback trims the engagement side, not the profile side.
Other credits are separate: data graph refreshes and identity resolution are billed separately and have their own schedules.
Manual publishing relies on people: if a one-off send relies on Publish Now and nobody presses it, the audience is stale. Put the publish on the campaign checklist.
No documented saving figure: Salesforce says a wider lookback means more data, but doesn’t put a number on it. Measure your own before and after.

This solution isn’t right if… you rely on near-real-time audiences (rapid or real-time segments), or your audience logic genuinely needs years of history. In that case, keep the window and work the schedule harder.

Wrap-up

Segment credits rarely come from one big mistake. They come from a hundred small defaults, repeated every day.

Two settings, checked once a quarter, put you back in control.

If you want the bigger picture on where Data 360 credits go, my post on a Data 360 implementation for global brands walks through the rate card line by line. And if any of your segments sit on federated data, Data Cloud zero copy: the hidden trade-offs explains why each refresh can cost more than you’d expect.

This is Next Level #7. All tips: Next Level Tips. Got a hidden tip of your own? I’d love to hear it.

November 6, 2026

Agentforce Marketing domains: essentials & confusing trio

You open Setup in Marketing Cloud Next / Agentforce Marketing, type “domain” into Quick Find, and get a small list back.

Authenticated Domains. Authorized Email Domains. Links, with a “Manage Domains” section inside it.

Three settings that sound alike but do three quite different jobs.

If you’re coming from Marketing Cloud Engagement, it’s tempting to file all of this under “the SAP bit” and hand it to IT. But Marketing Cloud Next domains don’t map one-to-one to what we had before. Get them wrong and the result isn’t a warning, it’s emails that don’t send, replies that vanish, or links that carry somebody else’s brand.

Salesforce covers this across Help articles, a knowledge article and the Marketing Cloud Next Email Sending Essentials Trailhead module. Read together, they’re pretty clear about what each domain is for.

And then there’s Reply Mail Management, which quietly decides what happens when a customer hits “Reply”.

So, let’s have a look.

Marketing Cloud Next domains in a nutshell

Authenticated domain — MUST. The subdomain you send from. Without one, there is no authenticated email sending at all.
Authorised email domain — CONDITIONAL. Only needed for dynamic reply-to addresses, or for CC (including treating internal staff as internal recipients).
Email tracking link domain (branded domain) — RECOMMENDED. Puts your brand on tracked links instead of a default Salesforce domain. Optional, but I’d set one up on every implementation.
Reply Mail Management (RMM) — configured on the authenticated domain. It filters auto-replies, processes opt-out keywords and forwards real replies to an inbox.

Decision flow showing which Marketing Cloud Next domains you need: authenticated always, authorised for dynamic reply-to or CC, tracking for branded links — Which Marketing Cloud Next domains do you actually need?

First, what do we mean by “domain” here?

A few terms that every conversation about Marketing Cloud Next domains leans on:

Root domain — your organisation’s main domain, e.g. example.com.
Sending subdomain — a subdomain used only for marketing email, e.g. mail.example.com. This becomes your authenticated domain.
From address — a display name plus a username (the local part) on an authenticated domain, e.g. Example Offers <offers@mail.example.com>.
Functional subdomains — prefixes Salesforce adds to your sending subdomain to route inbound mail: reply., bounce. and leave. (unsubscribe handling). Each needs a CNAME record pointing at Salesforce-managed inbound servers.
Verification vs activation — your IT team publishes the DNS records, Salesforce checks them, and only then does the domain’s status become Active.

Keep that last one in mind. Quite a lot in Marketing Cloud Next only appears once the domain is active.

Authenticated domains: the one you can’t skip

If you’ve set up Sender Authentication Package (SAP) in Marketing Cloud Engagement, this will feel familiar. Familiar, but not the same.

An authenticated domain proves to inbox providers that your organisation is the legitimate sender. Salesforce says it plainly in the sending domain setup article: “To send authenticated emails, you must set up and verify your sending domains.”

Where: Setup → Authenticated Domains → Add Domain.

What you enter: the subdomain (e.g. mail.example.com), then a display name and username for the first from address — Salesforce creates that initial from address alongside the domain.

DNS records Salesforce generates (per the CNAME records article):

three DKIM CNAMEs (s1-, s2-, s3-e360-…._domainkey)
CNAMEs for the reply., bounce. and leave. functional subdomains
a DMARC TXT record at _dmarc

Activation: after IT publishes the records, tick “I completed my changes with my DNS provider” and click Activate my Domain. Propagation can take up to 48 hours.

More from addresses: Setup → Authenticated From Addresses → Add From Addresses. Each one becomes available for sends that use that domain.

Required: Yes. This is the only one of the three that’s a hard MUST.

Watch-outs:

Salesforce’s sample DMARC record uses p=reject. The documentation warns that a reject policy at the root domain can affect all corporate email from that domain, so involve whoever owns your email security before publishing it.
Use a dedicated subdomain. Don’t share it with Marketing Cloud Engagement or another platform.

That’s a pretty big deal: no authenticated domain, no sending, and none of the other Marketing Cloud Next domains in this post work either.

Example scenarios

A retailer authenticates mail.example.com and adds three from addresses on it: Offers, Orders and the Style Team.
A group with two brands authenticates mail.brand-a.com and mail.brand-b.com separately, so each brand keeps its own sending reputation.

Authorised email domains: only when you need them

Now this one is particularly interesting, because it’s the most misunderstood of the Marketing Cloud Next domains.

“Authorised domains are just authenticated domains with a different name.”

Well… no. Salesforce’s authorised email domains article goes out of its way to say “authorized email domains aren’t the same as authenticated domains.”

Authenticated domains are the ones you send from.
Authorised domains are the ones you allow Marketing Cloud Next to use for CC or dynamic reply-to addresses.

And they don’t need to match. Salesforce’s own example sends from mail.example.com and authorises example.com. Once verified, any address on the authorised domain can be used as a dynamic reply-to or CC address.

Where: Setup → Authorized Email Domains (verified with a TXT record).

Used by:

Dynamic reply-to — the reply address is resolved per recipient, e.g. their account manager.
CC — under Unified Messaging → Send Settings. The CC article notes that “if authorized domains aren’t set, then all recipients are considered as external recipients”, so your own staff on CC are treated as external.

Required: Only for the features above. Salesforce states: “If you use Reply Mail Management (RMM), you don’t need to configure an authorized email domain. RMM generates a system-managed reply address.”

Watch-out: a dynamic reply-to sends replies straight to your own mail server. As I read it, that means they never reach Salesforce’s reply. subdomain, so RMM’s filtering and opt-out keyword handling can’t touch them.

Example scenarios

A B2B team wants replies to go straight to each contact’s account manager at @example.com, so they authorise example.com and use a dynamic reply-to.
A bank CCs the relationship manager on onboarding emails and wants them counted as internal recipients.

Email tracking link domains: optional, but don’t skip it

The third of the Marketing Cloud Next domains is all about links. Every tracked link in your email is rewritten so Salesforce can record the click. The question is simply whose domain the rewritten link shows.

Without a custom domain, Salesforce’s knowledge article on email link rewriting says links use a default domain, similar to cdp.tracking.e360.salesforce.com. With a branded domain, they show something like go.example.com instead.

Where: two steps, per Trailhead.

Setup → Certificate and Key Management → Create CA-Signed Certificate → download the CSR → have a certificate authority sign it → upload the signed certificate.
Setup → Links → Manage Domains → Create New → enter the domain → select that certificate → Save. Then publish the required CNAME and activate it.

Prerequisites: an active authenticated domain, plus a valid CA-signed HTTPS certificate. Trailhead even calls this out: if you get a generic error on save, check the sending domain is fully authenticated.

Required: No. Once active, you can select it for your sends.

Watch-outs, all from the same knowledge article:

The unsubscribe link ({$link.EmailAddressOptOutUrl}) is never rewritten with your custom domain. It always uses the default domain.
The Preference Manager link ({$link.PreferenceCenterUrl}) uses your org’s My Domain, not the tracking domain.
Marketing App for Salesforce Foundations, Pro Suite and Starter can’t set up a custom tracking domain at all.

So even with a branded domain, you’ll see three different domains in the footer area of one email. Nobody wants a QA tester raising that as a bug at 6pm before launch, so tell them first.

If a client asked me tomorrow, I’d still put a tracking domain in the first sprint. Branded links look more trustworthy to subscribers, and the certificate lead time is the bit that always takes longer than planned.

Example scenarios

A charity wants donors to see go.charity.org in link previews, not a Salesforce URL, before they click “Donate”.
A security-conscious insurer, where internal phishing training teaches staff to check link domains, needs links that match the brand.

One brand, three domains — and the functional subdomains Salesforce adds

Marketing Cloud Next domains compared

	Authenticated domain	Authorised email domain	Tracking link domain
Purpose	Send authenticated email	Allow dynamic reply-to and CC addresses	Brand rewritten, tracked links
Required?	Yes — MUST	Only for dynamic reply-to / CC	No, but recommended
Typical example	`mail.example.com`	`example.com`	`go.example.com`
DNS	DKIM CNAMEs, functional subdomain CNAMEs, DMARC TXT	TXT verification	CNAME
Extra	From addresses, RMM	—	CA-signed certificate
Setup path	Authenticated Domains	Authorized Email Domains	Certificate and Key Management, then Links
Depends on	Nothing	Nothing	An active authenticated domain

Setting up Reply Mail Management

Here’s where it gets interesting.

Every marketing email invites a reply, whether you like it or not. Out-of-office messages, “please remove me”, genuine questions, angry complaints. RMM decides which of those deserve a human.

Where: Setup → Authenticated Domains → the dropdown next to your domain → See Details → Reply Mail Management. The tab only shows its options once the domain is active.

The settings (per the RMM Help article and Trailhead):

Delete auto-responses — removes automatic replies and out-of-office messages.
Auto-response — sends an optional acknowledgement to replies that aren’t filtered out.
Routing — forwards the remaining replies to one monitored inbox or designated user.

Opt-out keywords (always on with RMM): RMM evaluates every manual reply. If unsub, unsubscribe, opt-out, remove or stop appears in the first 200 characters of the body, the sender is unsubscribed.

If you don’t set a forwarding address: Salesforce says incoming messages are “logged and deleted”. Not stored somewhere for later — deleted.

Domain level, not from-address level: of all the Marketing Cloud Next domains, RMM lives only on the authenticated domain, and there are no RMM settings on the from address. Every from address on mail.example.com shares the same filters, auto-response and routing. Trailhead confirms the opt-out handling “applies to all messages sent from your authenticated domain and can’t be turned on per campaign.”

That last point shapes everything that follows.

Reply Mail Management flow: a reply reaches the reply subdomain, auto-replies are deleted, opt-out keywords unsubscribe the sender, others get an auto-response and are forwarded or logged and deleted — How Reply Mail Management handles a reply

Reply scenarios: how RMM handles real replies

So, let’s walk through what actually lands in the reply inbox, and which settings deal with it.

1. An out-of-office reply that should just disappear

“I’m away until Monday with limited access to email.”

Setting: Delete auto-responses → on.

Outcome: it’s filtered out and deleted before it reaches anyone. That’s the cheapest win in RMM, and with a big send it’s the difference between a usable inbox and thousands of holiday notices.

2. A reply that should go to the right person

“Can someone from the events team call me about the venue?”

Setting: Routing → forward to the inbox that team monitors, e.g. events-team@example.com.

Outcome: the reply is forwarded and a human picks it up. Make sure that inbox is genuinely watched, and allowlisted too — a community test found forwarded replies landing in spam.

3. A reply that expects a response

“Does the 20% code work on sale items?”

Settings: Auto-response → on (e.g. “Thanks — we’ve got your message and will reply within two working days”), plus Routing → a customer service inbox.

Outcome: the customer gets an instant acknowledgement, and the question reaches someone who can actually answer it. The auto-response is a holding message, not the answer, so keep it generic (in a community write-up, the auto-reply didn’t support merge fields).

4. A reply that should go to different people depending on conditions

Event questions to the events team, order questions to customer service, B2B replies to the account manager.

The catch: RMM routing takes one forwarding address per authenticated domain. There’s no rule builder inside RMM. So the “conditions” have to come from somewhere else:

Condition = brand or business line → separate authenticated domains. Send events email from events.example.com and offers from offers.example.com. Each domain gets its own RMM routing address.
Condition = the recipient → dynamic reply-to. Authorise example.com and resolve the reply-to per contact, e.g. the account owner. Replies skip RMM and go straight to that person.
Condition = the content of the reply → route downstream. Forward everything to one shared mailbox and apply rules there: mailbox rules, or Email-to-Case with case assignment in Service Cloud.

If I were advising a client, I’d start with the third option. It keeps RMM’s filtering and opt-out handling in play, and the routing logic lives somewhere a service team already maintains. I’d only split domains when there’s a reputation or brand reason to do it anyway.

5. A reply that’s really an unsubscribe

“STOP sending me these.”

Setting: nothing extra. Opt-out keywords are processed automatically.

Outcome: “stop” is in the first 200 characters, so the sender is unsubscribed without anyone lifting a finger. A reply that leads with three paragraphs of complaint before saying “remove me” won’t trigger it, though, so your routed inbox still needs a human eye.

Reply	RMM setting	What happens
Out-of-office	Delete auto-responses	Deleted
Question for a team	Routing	Forwarded to one inbox
Needs an answer	Auto-response + Routing	Acknowledged, then forwarded
Different people by condition	Separate domains, dynamic reply-to or downstream rules	Depends on the pattern
“Stop” / “unsubscribe”	Always on	Sender unsubscribed
Anything, with no routing address	—	Logged and deleted

So what should we actually take away from all this?

1. Which domain lets me send?

Only the authenticated domain. Of the three Marketing Cloud Next domains, it’s the one hard MUST, and everything else either depends on it or is optional.

2. Do I need an authorised domain?

Only if you use dynamic reply-to or CC. If replies go through RMM, Salesforce says you don’t.

3. Is a tracking link domain worth it?

Yes, for brand trust. Just remember the unsubscribe and Preference Manager links won’t use it.

4. Where do replies go?

To the system-managed reply address on your reply. subdomain, then through RMM’s filters, then to one routing address — or into the bin if you haven’t set one.

5. Can different senders route replies differently?

Not within one domain. RMM is set per authenticated domain, so conditional routing means separate domains, dynamic reply-to or rules downstream.

The bigger picture

Marketing Cloud Next domains feel like plumbing. You set them up once, hand the DNS to IT, and forget about them.

But in Marketing Cloud Next they quietly decide three things your marketers care about: whether email sends, whose brand is on every link, and whether a customer’s reply reaches a human.

So the question to ask in a discovery workshop isn’t:

“Have we set up our Marketing Cloud Next domains?”

It’s:

“Which domains, for which senders, and where should every reply end up?”

The most common mistake I’d expect is treating reply handling as an afterthought. Because it’s the one part of email where the customer is talking to us.

Well… are we listening?

If reply handling has you thinking about opt-outs, my post on Marketing Cloud Next consent covers how subscriptions and consent fit together. And if you’re working through a Marketing Cloud Next setup, I’m always happy to compare notes.

November 5, 2026

Data 360 for global brands: buried traps

A global brand. Forty markets. Some run as single countries, some as clusters.

And one big ambition: a single view of every customer, everywhere.

That’s usually how a Data 360 implementation (yes, the product we all still call Data Cloud half the time) starts its life on a whiteboard.

Cool, right?

But here’s the thing. The whiteboard version hides five decisions that get locked in early — and some of them are genuinely painful to undo later.

Salesforce has published a fair amount of guidance on this: architect decision guides, Trailhead modules and a fresh Flex Credits rate card. Read together, they tell a clearer story than any one of them alone.

So, let’s have a look.

Data 360 implementation in a nutshell

Instances: as few as possible, but one per region where residency demands it.
Data spaces: carve by region or market cluster, not by every country.
MDM: Data 360 is a system of reference. Your MDM stays the system of record.
Snowflake: ingest what you govern centrally, federate what changes often, share back what analysts need.
Credits: unification is the expensive line on the rate card, by a long way. Design identity resolution like it’s a budget decision — because it is.

First, the building blocks

If you’ve delivered a single-market Data Cloud implementation before, most of this is familiar. What changes at global scale is how these pieces combine:

Home org — the Salesforce org where your Data 360 instance is provisioned. Its region is the instance’s region.
Companion orgs — other orgs connected through Data Cloud One. They can use shared data, but they can’t ingest or unify data themselves.
Data spaces — logical partitions of data, metadata and processes inside one instance.
Unified profile — the result of identity resolution: a linked view across sources, not a mastered record.
Flex Credits — the consumption currency. Under this model, most processing is billed per million rows, with a different multiplier per usage type.

How many Data 360 instances do you actually need?

This is the first decision in any Data 360 implementation, and the hardest to reverse.

Salesforce’s Data 360 provisioning decision guide is clear: create “the least number of Data 360 instances as possible, ideally by using Data Cloud One”. Multiple instances make sense “only… when required by compliance, residency, or organizational autonomy”.

And the region? It’s fixed at provisioning, inherited from the home org. Changing the home org later is described as “difficult and disruptive”.

Now here’s the part people often miss. Trailhead says it plainly: “Data spaces don’t solve data residency needs.”

So if your EU customer data must stay in the EU, that’s a separate instance, not a separate data space.

Where the work runs: in the home org’s region. Hard to change later: home org, region, instance count. Watch-out: zero-copy federation is region-sensitive too — a Snowflake account in the EU pairs naturally with an EU instance.

If a client asked me tomorrow, I’d start with one question: which markets legally can’t share an instance? That list sets the instance count. Everything else is preference.

Example scenarios

A retailer with strict EU residency commitments and a US business: one EU instance, one US instance, each unifying its own region.
A B2B manufacturer with no residency constraints across 30 markets: one instance, with the regional CRM orgs connected as companion orgs.

Data 360 implementation topology with regional instances, market data spaces, companion orgs, MDM and Snowflake

Carving up markets with data spaces

Inside an instance, data spaces do the market separation. Salesforce describes them as a way to “segregate data, metadata, and processes by categories such as brand, region, or department”.

Segments, calculated insights and activations all run in the context of a data space. Each data space gets its own permission set, so market teams only see what they should.

The tempting move in a multi-market Data 360 implementation is one data space per country.

Well… you can try. But the number of data spaces depends on your licences, identity resolution rulesets are configured per data space, and ruleset runs are throttled per data space too. Forty countries means forty rulesets to design, test and pay for.

What it does: separates data, metadata, permissions and processing by market. Good grain: a region or a cluster of markets that share processes, languages or teams. Watch-out: a customer who appears in two data spaces is unified separately in each. Cross-market unification and strict separation pull in opposite directions.

Example scenarios

A beauty brand groups its 12 EMEA markets into three data spaces (UK & Ireland, DACH, Southern Europe), each with its own marketing team.
A travel company keeps one global data space for loyalty members who book across countries, plus a separate space for a sub-brand.

Data 360 and your MDM: reference, not record

This one comes up in nearly every enterprise Data 360 implementation.

“Once Data 360 is live, we won’t need the MDM.”

But the documentation gives us more nuance than that. Salesforce says identity resolution “creates complete, actionable views of your customers but doesn’t create golden records and isn’t a master data management (MDM) system“. Unified profiles “act as a system of reference.”

That’s an important distinction.

So the sensible pattern is to let each do its job:

MDM owns the golden record, survivorship and stewardship.
Data 360 ingests the MDM’s mastered IDs and uses them as a match key. The Party Identification rule does exactly this — an exact match on identification number, name and type.
Unified profiles then stitch in everything the MDM doesn’t hold: engagement, web, commerce and app behaviour.

Integration routes: Informatica (now part of Salesforce) offers a Data 360 connector and has announced MDM integration with Data 360; MuleSoft’s Data Cloud connector can stream records through the Ingestion API. Watch-out: I’d be careful about writing the unified profile ID back into the MDM as if it were a master key. Unification is rule-driven, so profiles can merge or split when rules or data change. Keep the MDM ID as the durable key.

Example scenarios

An insurer’s MDM holds one party ID per policyholder across 15 countries; Data 360 uses it as the primary match rule, with email and phone as fallbacks.
A brand without an MDM uses fuzzy name plus exact normalised email — and accepts that this is a system of reference, not a mastered record.

Snowflake: ingest, federate or share?

If your global data team already lives in Snowflake, your Data 360 implementation gets three ways to work with it. I covered the mechanics in my zero copy trade-offs post, so here’s the multi-market lens.

Salesforce’s interoperability decision guide gives the rule of thumb: ingest data that needs central governance, lineage or compliance; federate when governance at the source is acceptable.

Ingest — copy into Data 360. Best for identity data that feeds unification.
Live query federation — Data 360 queries Snowflake in place. Compute runs on Snowflake.
Accelerated (cached) federation — Data 360 keeps a cached copy, refreshed between 15 minutes and 7 days. The guide notes incremental refresh “supports upserts only”, so deletions need a periodic full refresh.
Share out — Data 360 objects appear in Snowflake for analysts. Salesforce’s latest Snowflake update describes them as native Iceberg tables.

Watch-out: Snowflake’s documentation notes you can’t share an external data lake object, or a DMO mapped to one, back out. Federated data doesn’t round-trip.

And here’s the interesting part for global brands: the guide says same-region file federation on AWS consumes no credits for the rows accessed, while cross-region does. Region alignment between Snowflake and each Data 360 instance is a cost decision, not just a latency one.

Example scenarios

Ten years of order history in Snowflake, used for lifetime-value segments: federate with acceleration on a daily refresh.
Customer master data from the MDM, landed in Snowflake first: ingest it, because it drives identity resolution.

Decision flow for Snowflake data in a Data 360 implementation: ingest, live query, accelerated federation or file federation

Where Data 360 credits really go

Now things get a little more interesting.

The Flex Credits rate card (updated 31 August 2026) prices most work per million rows, with a multiplier per usage type. At the base tier:

Unification: 75,000 credits per million rows
Streaming pipeline: 3,500
Activation: 60
Segmentation: 50
Prep: 40
Queries: 3

Wow — unification costs 1,250 times more per row than activation.

So the instinct to count activations first is understandable, but the rate card points somewhere else entirely. Identity resolution design is where a Data 360 implementation wins or loses on cost.

Data 360 Flex Credits multipliers per million rows, showing unification far above other usage types

A few patterns follow from that:

Unify only the profiles you’ll use. Billing is on rows processed, not on unified profile count. Filter dormant, test and duplicate records before they reach identity resolution — Trailhead’s own example is ingesting only profiles active in the last year.
Freeze rulesets before go-live. A Salesforce architect writing on the Salesforce blog notes that changing a ruleset, match rule or reconciliation rule “triggers a full reprocessing of every source profile”. Iterate in a sandbox on a sample, not in production on 80 million rows.
Batch by default, stream by exception. Streaming pipelines cost 3,500 per million rows against 40 for prep. Most markets don’t need second-by-second freshness.
Match refresh cadence to change. Hourly is 24 times daily. Segments, insights and transforms should refresh as often as their inputs actually change.
Watch federated segments. Without acceleration, every segment preview, refresh and activation runs a new live query — and Salesforce’s credit guidance for federation bills on rows scanned, even ones filtered out.
Use the tiers. Multipliers drop as monthly usage per type grows, and sandbox has its own rate. Plan builds and backfills with that in mind.
Consider the profile models. The Data 360 pricing page also offers per-profile pricing that “un-meters the usage types used to form unified profiles”. For very large, stable populations, that might change the maths.

Monitoring: Digital Wallet shows consumption by usage type in near real time; the monthly statement remains the source of truth.

Example scenarios

A brand with 60 million source records cuts unification volume by a third by excluding contacts with no activity in three years.
A market team switches abandoned-basket segments from hourly to every four hours after seeing basket data only lands four times a day anyway.

Data 360 implementation decisions at a glance

Decision	Options	Choose when	Credit impact
Instances	One global vs one per region	Residency or compliance requires separation	Duplicate pipelines and unification per instance
Data spaces	Per country vs per market cluster	Teams, processes and consent rules align	Rulesets and runs multiply per space
MDM	Data 360 as master vs MDM ID as match key	An MDM already masters customers	Exact match keys keep unification lean
Snowflake	Ingest, live query, accelerated, share	Governance vs freshness vs volume	Live: per query. Cached: per refresh
Freshness	Streaming vs batch	Use case truly needs real time	Streaming costs far more per row

So what should we actually take away from all this?

Here are the five questions I’d bring to the first Data 360 implementation workshop.

1. Which markets legally can’t share an instance?

That answer sets your instance count and your home org regions. Data spaces won’t fix it later.

2. What’s the right grain for a data space?

Usually a region or market cluster with shared teams and processes — not every flag on the map.

3. Who owns the golden record?

If you have an MDM, let it keep that job. Feed its ID into Party Identification and treat unified profiles as a system of reference.

4. Where does each Snowflake table belong?

Identity data in, large behavioural history federated, and analyst-facing data shared out — with regions aligned.

5. How many rows will identity resolution actually process?

Estimate it early in your Data 360 implementation, before you size the contract. It’s the line that dominates the bill.

The bigger picture

A global Data 360 implementation isn’t really a technical rollout. It’s a set of early commitments about geography, ownership and cost.

The better question isn’t:

“How do we get one view of every customer?”

It’s:

“Which customers need to be unified, where are they allowed to live, and how often does that view need to change?”

Answer those three and the architecture — and the bill — mostly design themselves.

The real traps aren’t in the features. They’re buried in the first workshop.

If you’re weighing up Snowflake specifically, my post on Data Cloud zero copy trade-offs goes deeper. And if you’re planning a multi-market rollout, I’m always happy to compare notes.

November 1, 2026

Braze brings Salesforce its hidden real-time edge

Salesforce is buying Braze.

On 20 October, Salesforce announced it had signed an agreement to acquire Braze for roughly $5.66 billion in enterprise value, or $47.50 in cash per share.

Cool, right?

The first reaction I saw in most feeds was a version of the same thing:

“Another marketing platform? Salesforce already has Marketing Cloud.”

Fair question. But it’s not the most useful one.

The better question about the Braze Salesforce deal is this: what does Braze do well that most of us find hard to do in the Salesforce stack today, and where would it plug in?

Salesforce’s press release gives us a surprising amount of detail on that. And Braze’s own documentation fills in the rest.

So, let’s have a look.

The Braze Salesforce deal in a nutshell

The acquisition: ~$5.66bn enterprise value, $47.50 cash per Braze Class A share.
Timing: expected to close in Salesforce’s fiscal year 2028, subject to Braze shareholder and regulatory approval.
Specialities
1. Real-time, event-streaming engagement
2. Deep mobile and in-app channels
3. AI decisioning across content, offers, channels and timing
4. composable data plumbing, in from the warehouse and back out again
The pitch: Braze is expected to complement all four layers of Salesforce’s architecture, not just Marketing Cloud.

Four Braze specialities in the Braze Salesforce deal: real-time streaming, mobile and in-app, AI decisioning, composable data

First, what is Braze, and how is it different?

If you’ve spent your career in Marketing Cloud Engagement, Braze can look familiar at first glance. Journeys, segments, email, SMS, push.

But the design underneath is different. A few terms help:

Event streaming — customer behaviour (an app open, a basket update, a payment) flows in continuously and can change a profile or a journey within moments, rather than waiting for the next scheduled import.
Canvas — Braze’s journey builder. Roughly the equivalent of Journey Builder, but designed around those live events.
BrazeAI — the umbrella for Braze’s AI features, including Operator, agents, Intelligent Timing, Intelligent Channel and Decisioning Studio.
Currents — Braze’s outbound stream of engagement events (sends, opens, clicks and so on) to warehouses and other tools.

Salesforce describes Braze’s architecture as “cloud-native, event-streaming… optimized for high-volume, real-time B2C engagement”, powering “trillions of messages and journey actions each year”.

That’s the key distinction, and it’s the lens I’d use for the whole Braze Salesforce story. Some platforms are built around the campaign. Some are built around the moment.

1. Real-time, event-streaming engagement

This is the headline speciality in the Braze Salesforce deal, and the one Salesforce leads with.

What it is: Braze takes live signals from apps, websites and back-end systems, updates the profile continuously, and lets a Canvas react while the customer is still in the session.

Today in Salesforce: most of us build engagement around data extensions, scheduled automations and journey entry events. It works, but “real time” usually involves some engineering.

What Braze adds: behaviour-led journeys as the default, not the exception. Salesforce says the event-streaming architecture turns “live customer signals and data from cloud data warehouses and other platforms” into messages and journeys.

Where it’s expected to plug in: Data 360 for the customer context, Marketing Cloud for orchestration.

Watch-out: Futurum’s Keith Kirkpatrick puts it bluntly: “Salesforce will now run two engagement engines”. Which one owns a given journey is still an open question.

Braze Salesforce real-time loop: live signal into a Braze Canvas, BrazeAI decides, message sent, Currents streams results back to Data 360

Example scenarios

A food delivery app sees a basket abandoned at checkout and nudges in-app within the same session, not the next morning.
A fitness brand notices a member hasn’t booked a class in 10 days and triggers a personalised push, with the email as fallback.

2. Mobile and in-app depth

If Braze has a reputation for anything, it’s this. And it’s the gap many of us feel most when a client’s app team joins the room.

What it is: channels that live inside the product, not just the inbox. Braze’s channel documentation lists in-app messages, Content Cards, Banners, push, plus email, SMS/MMS/RCS, WhatsApp, LINE, KakaoTalk and webhooks.

What Braze adds:

Content Cards — “a highly targeted, dynamic stream of rich content”, embedded in apps and websites.
Live Activities — iOS lock-screen updates (think delivery trackers), which Braze can start and update remotely via its Live Activities API.
In-app messages and Banners — shown in context while the customer is using the product.

Where it’s expected to plug in: Salesforce says Braze’s “deep mobile and app capabilities, including in-app messages, personalized content feeds, and live updates” will work alongside email, web and messaging channels.

Watch-out: these channels need the Braze SDK in the app. So the mobile team, not just the marketing team, becomes part of the conversation.

Example scenarios

A retailer’s app shows a Content Card with a member-only offer that disappears the moment it’s redeemed in store.
A travel brand runs a Live Activity on the lock screen showing gate changes and boarding status.

3. AI decisioning with BrazeAI

Now this one is particularly interesting.

What it is: AI that chooses what to send, where and when for each customer. Braze lists Intelligent Channel, Intelligent Timing, Item Recommendations, Operator, agents and Decisioning Studio under BrazeAI.

What Braze adds: BrazeAI Decisioning Studio, which started life as OfferFit (acquired by Braze in 2025). Braze describes it as using reinforcement learning and contextual bandits to choose the message, channel, timing and incentive for each customer, continuously experimenting rather than relying on one-off A/B tests.

Where it’s expected to plug in: Salesforce says that bringing Braze’s AI decisioning together with “Salesforce’s customer context and Agentforce” would connect marketing to commerce, sales and service.

Watch-out: more automated decisions raise governance questions. Who approves the offer rules? Who owns the decision when the model picks something odd?

Example scenarios

A subscription business lets the model choose between a discount, a free month or no offer at all for each at-risk customer.
A bank tests which of five onboarding nudges, on which channel, gets new customers to set up a direct debit.

4. Composable data plumbing

This one is quieter, but for architects it might be the most useful.

What it is: Braze is built to work with data where it already lives. Its data ingestion guide describes two flavours:

Persistent — Cloud Data Ingestion (CDI) syncs warehouse tables onto Braze profiles, as often as every 5 minutes.
Zero-copy — CDI Segments and CDI Canvas triggers query the warehouse without writing to the profile.

And on the way out, Currents is “a real-time data stream of your engagement events” to warehouses, analytics tools and CDPs.

Where it’s expected to plug in: Data 360. According to the press release, Salesforce and Braze “share a commitment to an open, composable approach”, and Data 360 already leans heavily on zero-copy.

Watch-out: I couldn’t find an official native Braze ↔ Data 360 connector today. Current Salesforce links are mostly webhooks, APIs and third-party connectors.

Example scenarios

Loyalty tiers stay in Snowflake and trigger a Canvas directly, without copying every attribute into Braze.
Every send, open and click streams back via Currents so the service team sees the full message history.

Where Braze fits in the Salesforce ecosystem

Here’s the part of the Braze Salesforce announcement I found most telling.

Salesforce doesn’t frame this as “Braze joins Marketing Cloud”. It says Braze is expected to complement all four layers of its architecture: Data 360, Customer 360, Agentforce and SIForce.

Braze Salesforce fit: where Braze capabilities are expected to plug into Data 360, Customer 360, Agentforce and SIForce

Kirkpatrick at Futurum summarises the split neatly: “Data 360 supplies the customer data; Braze supplies the decisioning and the channels that deliver the message.”

The press release names SIForce but doesn’t explain it, so I’d wait for more detail before reading too much into that layer.

Here’s how the four specialities line up in a combined Braze Salesforce stack:

Braze speciality	What it brings	Expected Salesforce fit	Open question
Real-time streaming	Profiles and journeys that react to live events	Data 360 + Marketing Cloud	Which engine owns the journey?
Mobile and in-app	In-app messages, Content Cards, Banners, Live Activities	Marketing Cloud (Customer 360)	Does it replace or sit beside MobilePush?
AI decisioning	BrazeAI, Decisioning Studio (formerly OfferFit)	Agentforce	How do agents and Decisioning Studio share decisions?
Composable data	CDI in (persistent or zero-copy), Currents out	Data 360	Native connector, or more plumbing?

So what should we take away from the Braze Salesforce deal?

A few questions I’d keep handy for the next client conversation.

1. Which engine owns the journey?

For now, both do. Until Salesforce publishes a roadmap, decide per use case, not per platform. MarTech’s Constantine von Hoffman makes the same point: teams need to know “which system owns journey orchestration”.

2. Where does the profile live?

Data 360, Braze, the warehouse, or all three? The answer drives identity, consent and reporting, and it’s worth writing down before anyone builds anything.

3. Is the use case batch or behaviour-led?

A monthly newsletter doesn’t need event streaming. A basket-abandon nudge inside the app does. Sorting use cases this way is useful whatever happens next.

4. What changes before close?

Nothing, officially. The acquisition is expected to close in FY2028 and needs approvals. Braze’s CEO says they’ll “continue building as Braze”. So existing contracts and roadmaps stand for now.

The bigger picture

The Braze Salesforce deal is less about adding another tool and more about adding a speed.

Salesforce has the data layer, the CRM and the agents. What Braze brings is a mature, battle-tested way to act on behaviour in the moment, especially inside apps.

Will it be smooth? Well… that’s still the open question. West Monroe’s Alex Torgerson told TechTarget: “The strategic logic is sound, but the value hinges entirely on integration…and customer migration.”

So instead of asking:

“Should we move to Braze?”

I’d ask:

“Which of our journeys actually need to react in seconds?”

Because that’s the question the Braze Salesforce deal really puts on the table.

And that’s exactly where the real-time edge earns its place.

Want more on where Salesforce is taking marketing? Read my breakdown of smart features in the new Marketing Cloud Next.

October 25, 2026

Marketing Cloud Next consent: the hidden cube

“We’ve imported all the opt-ins. So why did nobody get the email?”

If you’ve started a Marketing Cloud Next project, there’s a good chance you’ve heard that question already. Or asked it.

Consent in Marketing Cloud Next looks straightforward on the surface. A subscription, an opt-in, a send.

Cool, right?

But here’s the thing worth paying attention to with Marketing Cloud Next consent: it doesn’t behave like the opt-out checkbox many of us grew up with in CRM, or the All Subscribers list in Marketing Cloud Engagement.

It has more dimensions than that. It starts at “no”. And it only counts if it arrives the right way.

Salesforce has a whole Trailhead module on consent management for Marketing Cloud Next, plus a detailed help article on the consent tools and concepts. And there are some interesting details buried in them.

So, let’s have a look.

Marketing Cloud Next consent in a nutshell

If you only have 30 seconds:

It’s a cube, not a checkbox: consent is stored per contact point (an email address or phone number), per subscription, per channel.
The default is “no”: no opt-in record means the message doesn’t go.
Channels have different rules: promotional email is checked, transactional email isn’t by default, and SMS, WhatsApp and RCS always are.
It lives in Data 360: and it has to be written through the consent service, not mapped straight into the data model.
Taking consent away has limits too: “unsubscribe from all” and SMS STOP are narrower than they sound.

The rest of this post is the detail behind those five lines.

First, what does Salesforce mean by consent here?

Salesforce says that Marketing Cloud Next manages all consent centrally using Data 360, with preferences stored as data model objects (DMOs).

The help documentation names four objects behind Marketing Cloud Next consent. Here’s what each one means in plain terms:

Communication Subscription: the topic someone can subscribe to, like “Newsletter” or “Product updates”. A default “Marketing” subscription is created for you.
Engagement Channel Type: the channel, such as email, SMS or WhatsApp.
Communication Subscription Channel Type: a subscription on a specific channel, for example “Newsletter by email”.
Communication Subscription Consent: the record that says whether a specific email address or phone number is opted in or out of that subscription on that channel, with the date and source.

Trailhead describes that last one as the record that “defines the ultimate truth”.

So that’s the one to keep your eye on.

The Marketing Cloud Next consent cube

The way I like to picture it is a 3-D table. A cube.

My first instinct was to call the three axes Contact — Subscription — Contact Point. But the documentation gives us a slightly more precise picture than that.

Salesforce says consent is “tied to the contact point value, as opposed to the Unified Individual record itself”.

So the person isn’t really an axis. The three axes are:

Contact point: the actual email address or phone number.
Subscription: the topic, like Newsletter or Offers.
Channel: email, SMS, WhatsApp or RCS.

Each cell in the cube is one Communication Subscription Consent: opted in, opted out, or (most of the time) empty.

The person sits outside the cube. They connect to it through their contact points.

The Marketing Cloud Next consent cube with axes for contact point, subscription and channel, showing one opted-in cell — Three axes, one cell per decision: contact point Ã— subscription Ã— channel

Salesforce’s partner workshop on consent describes four levels of consent, from the whole individual (Level 1) down to “a specific contact point value and a specific subscription type” (Level 4). Marketing Cloud Next supports Level 4, the most granular one.

That’s a pretty big shift.

What consent belongs to: the email address or phone number, not the person.
What carries across: nothing. Trailhead is clear that changing consent on one channel doesn’t affect the same subscription on another channel.
Watch out for: new email addresses. If a customer changes their email address, Salesforce says the historical consent does not automatically transfer over. The new address needs its own consent.

Example scenarios

Priya opts in to the Newsletter with her work email. Her personal email stays an empty cell, even though it’s the same person.
A retailer’s “Offers” subscription runs on email and SMS. A customer opts in to email offers, and that says nothing about SMS offers.

No record, no send

Now this one is particularly interesting if you’re coming from Marketing Cloud Engagement.

Marketing Cloud Next consent uses strict opt-in. According to Trailhead, if there’s no record, “the system assumes they have opted out”.

Not “unknown”. Not “probably fine”. Opted out.

As the module puts it, “the sheer absence of a recorded ‘Yes’ is enough” to stop the message.

So most of the cube is empty, and empty means no.

How strictly that applies depends on the channel and the type of message. The help article explains that the consent check requires you to pick a communication subscription when you send, and makes sure each recipient is opted in.

Promotional email: consent required.
Transactional email: consent checks are disabled by default. Admins can change the settings in Setup.
SMS, WhatsApp and RCS: consent required for any type of message.

And here’s the interesting part: for SMS, the partner workshop says the product “does not provide a mechanism to bypass SMS consent enforcement”. Even a delivery update needs an opt-in.

Example scenarios

40,000 CRM contacts are migrated without consent records. The first newsletter goes to almost nobody, because every cell is empty.
An order-shipped SMS fails for customers who only ever opted in to email. SMS has no transactional exemption.

Marketing Cloud Next consent by channel

Here’s the same thing as a table, because it’s a lot easier to scan:

Message	Consent check	Default	Opt-in record needed for
Promotional email	Yes	On	That email address + subscription + email channel
Transactional email	Optional	Off (can be turned on in Setup)	Only if the check is turned on
SMS (any type)	Yes	On, no bypass	That phone number + subscription + SMS channel
WhatsApp / RCS (any type)	Yes	On	That phone number + subscription + that channel

One nuance on transactional email: Trailhead says transactional emails don’t need a promotional subscription, but you should still respect global opt-outs. The workshop notes transactional email “may rely on a legitimate interest basis” under frameworks like GDPR.

That’s a legal call, not a technical one. Worth checking with whoever owns privacy on your project.

Consent has to travel through Data 360

This is the part that catches most teams out.

Marketing Cloud Next consent lives in Data 360. So far, so expected.

But it’s not enough for the data to land in Data 360. It has to get there through the consent service.

“Consent is just data in Data 360, so we can load it with a data stream.”

Well… yes. But the documentation gives us more detail than that.

According to the partner workshop, sends read from an internal consent service and cache layer. That’s how “consent changes are immediately respected at send time”. The Create Consent action, for example, updates that cache first, then writes the record into Data 360.

Data streams and batch data transforms can write to the Communication Subscription Consent DMO. But they don’t update the cache, so the send may never see the change.

Trailhead says it plainly: “Updating the data model object (DMO) directly does not update the consent for Marketing as expected.”

So, which routes are supported? Salesforce’s troubleshooting article lists them:

Create Consent flow action: for forms, events and automation. It’s included by default in Signup Form campaign flows.
Consent Status component: for updating one record by hand on the contact page.
Consent Import: a CSV upload of up to 50,000 rows.
More than 50,000 rows: stage the data in a custom DMO, then run a Data 360-triggered flow that calls Create Consent.

Preference pages and unsubscribe links are the built-in way for subscribers to change consent themselves.

Anything else, the article calls “an unsupported write path”.

Supported and unsupported ways to write Marketing Cloud Next consent: through the consent service and cache, or straight into the DMO — Same Data 360 object, two very different outcomes

Older flow actions: Salesforce says not to use the MessagingConsent and MessagingConsentV2 flow actions. Create Consent replaces them.
Delay: expect around 15 minutes before an update shows up in Data 360, according to the troubleshooting article. The send check itself reads the cache.
Audit: a consent audit trail records every change, while the consent record itself only holds the current status.

Example scenarios

Consent from a legacy ESP is mapped into the consent DMO with a data stream. It looks perfect in Data Explorer, but the sends don’t pick it up.
A CRM opt-in field changes on a Contact. A record-triggered flow calls Create Consent so the change actually reaches Marketing Cloud Next.

Taking consent away

Taking Marketing Cloud Next consent away has its own nuances, and they’re worth knowing before a customer complaint teaches you.

Unsubscribe links: every promotional email needs one, or a link to the preference page. A click sets the consent record to opted out.
“Unsubscribe from all”: on the standard preference page, this removes the contact point from all existing subscriptions. Trailhead says it does not persist as a permanent block, so a subscription you create next month isn’t covered. (Though with default opt-out, nobody is opted in to it yet either.)
SMS STOP: STOP, CANCEL and UNSUBSCRIBE are recognised, but STOP only opts out of that specific sender number, not all SMS from the brand.
Deleting subscriptions: don’t. Salesforce warns that deleting a Communication Subscription permanently deletes all related consent history. Hide it from the preference pages instead.

Nobody wants to be the admin who tidied up an old subscription and took two years of consent history with it.

Example scenarios

A customer texts STOP to your marketing short code, then still gets texts from your service number. Each sender number is opted out separately.
A “Spring Sale 2025” subscription is no longer needed. Hide it from the preference page rather than deleting it.

So what should we actually take away from all this?

For me, the biggest takeaway is this:

“This contact is opted in” isn’t really a complete statement in Marketing Cloud Next.

Which address? For which subscription? On which channel?

When I’m working on Marketing Cloud Next consent, I’d ask four questions.

1. Which cell of the cube are we talking about?

Pin down the contact point, subscription and channel. If one of the three is missing, the answer is probably “not opted in”.

2. Does this message actually need consent?

Promotional email and anything on SMS, WhatsApp or RCS: yes. Transactional email: only if the check is turned on, and that’s a decision for your privacy team.

3. How is consent getting in?

Forms, imports, CRM sync, migrations. Every route should end in Create Consent, Consent Import or the Consent Status component, never a data stream straight into the DMO.

4. What happens when things change?

New email addresses, new subscriptions, STOP replies, retired topics. Each one has a rule, and none of them carry consent over for you.

The bigger picture

I really like where Salesforce has gone with Marketing Cloud Next consent.

Strict opt-in, per channel, per address, with an audit trail. That’s a privacy-first design, and it’s an essential foundation if you’re sending across email, SMS and WhatsApp at the same time.

But it does mean we need to change the question.

Instead of asking:

“Is this contact opted in?”

I’d ask:

“Is this email address or phone number opted in to this subscription, on this channel, and did that consent arrive through the consent service?”

That’s a much more useful conversation, especially early in a project, before the first send suppresses your whole audience.

Because, as we’ve seen, Marketing Cloud Next consent isn’t a checkbox. It’s a cube, it starts empty, and only the right tools can fill it in.

So the next time someone says, “But they’re opted in!”, you know what to ask:

“Well… opted in where?”

Curious how the AI side of the platform works? Read Smart features in the new Marketing Cloud Next.

October 18, 2026

Data Cloud zero copy: the hidden trade-offs explained

Zero copy is one of those Data Cloud features that sounds almost too good to be true.

Use the data sitting in Snowflake, Databricks, BigQuery or Redshift inside Salesforce… without copying it in.

Cool, right?

Quick naming note before we start: Salesforce renamed Data Cloud to Data 360 at Dreamforce 2025. Same platform, new name — so you’ll see both in this post, and in the documentation.

But here’s the thing I think is worth paying attention to with Data Cloud zero copy: it isn’t one single feature.

There are actually four different ways it can work.

Some never store your data in Data 360. One of them does.

Some run on your warehouse’s compute. Some don’t.

And the cost — in Data 360 credits and on your warehouse bill — changes quite a bit depending on which one you pick.

So, let’s have a look.

Data Cloud zero copy in a nutshell

If you only have 30 seconds:

Live query — Data 360 asks your warehouse; only the results come back.
Caching (acceleration) — a scheduled copy of the federated data, kept in Data 360.
File federation — Data 360 reads open-format files (Apache Iceberg) straight from your object storage.
Zero copy data sharing — the reverse direction: Data 360 data made available inside Snowflake, Databricks and co.

The rest of this post is the detail behind those four lines.

First, what does Salesforce mean by zero copy?

Salesforce describes zero copy as a technology that “enables enterprises to access and query data without copying it”.

It works in two directions:

Data in (zero copy data federation) — Data 360 uses data that lives in your lakehouse or warehouse, for things like segmentation and identity resolution, without ingesting it.
Data out (zero copy data sharing) — Data 360 data, such as unified profiles and calculated insights, is made available to an external platform without building an export pipeline.

Out of the box, Salesforce lists Snowflake, Databricks, Amazon Redshift and Google BigQuery. The Zero Copy Partner Network launched in April 2024 with AWS, Databricks, Google Cloud and Snowflake, and Microsoft and IBM have joined since.

Zero copy works both ways: federation in, sharing out

The “data in” side is where it gets interesting, because Data 360 has three different ways to read that external data.

Three ways in and where the work actually happens

Let’s get into it.

1. Live query (query federation)

This is the one most people picture when they hear “zero copy”.

When Data 360 needs the data, it sends a query to the external platform. According to Salesforce’s Data 360 Interoperability guide, the query is pushed down to the source, the warehouse does the work, and only the results come back.

Nothing is stored in Data 360.

Where the work runs: your warehouse
Freshness: as fresh as the source
Cost: Data 360 credits for each query and compute on your warehouse

Example scenarios

A segment filters on loyalty tiers stored in Snowflake — checked when the segment publishes, not loaded overnight.
Order history in Redshift that’s only used now and then for an audience, so a full ingestion pipeline isn’t worth it.

And here’s the bit to watch.

Salesforce calls this a “pay-per-query model”, and warns that costs “may spike significantly at high QPS”. Performance also depends on the external system — overly broad queries and joins between Data 360 data and federated data are common causes of latency, according to this Salesforce blog.

So “zero copy” doesn’t mean “zero cost”. It means the cost moves to query time.

2. Caching (accelerated query)

Now things get a little more interesting.

Acceleration — you’ll also see it called caching or Accelerated Query — “temporarily stores cached copies of federated data in Data 360”.

Yes… the zero copy option that involves a copy.

The cache refreshes on a schedule you configure, anywhere from 15 minutes to 7 days. Queries then hit the cache instead of your warehouse, which makes them faster.

Where the work runs: Data 360 (your warehouse only works during refreshes)
Freshness: as of the last refresh
Cost: Data 360 credits for the rows cached, plus external storage costs

One detail that’s easy to miss. Salesforce notes that “incremental refresh supports upserts only. Deleted records aren’t removed from the cache.” So a periodic full refresh is a good idea, otherwise deleted records can quietly hang around in your segments.

Salesforce also says caching is “not suitable for sub-second decisioning”.

Example scenarios

A daily dashboard built on a million records and viewed 20 times a day — read a lot, changes a little.
A product catalogue that changes weekly but is used in almost every segment.

3. File federation

The third option is the one the Salesforce blog calls “the third and best way” to connect to data lakes.

Instead of asking your warehouse’s engine to run a query, Data 360 reads the data files directly from object storage — Amazon S3, Google Cloud Storage or Azure Data Lake Storage — using open table formats like Apache Iceberg. It’s read-only.

Your warehouse’s compute isn’t involved at all.

Where the work runs: Data 360, reading the files directly
Freshness: whatever is in the files — Salesforce says it’s “not suitable for real-time dashboarding”
Cost: no cost on the external lake, and very little in Data 360 if you stay in the same region

And region really matters here.

The blog says that if your data lake and Data 360 are in the same region, “the cost is almost zero on both sides”. The architects’ guide goes further: for same-region setups, “credits aren’t consumed for the rows that are accessed”, while cross-region or cross-cloud access does consume credits.

Performance depends on file format, partitioning and network I/O, so a well-organised lake matters.

A note on availability: Salesforce’s zero copy page still labels file federation as beta, while Databricks’ documentationlists it as generally available. Check the current status for your platform before you design around it.

Example scenarios

Years of transaction history in Iceberg tables on S3 — far too big to ingest, but useful for segments.
Propensity scores written to the lakehouse by the data science team, read by Data 360 in the same region.

4. Zero copy data sharing

And finally, the other direction.

Data sharing makes Data 360 data available in an external platform, without an export job. The setup, as described in Snowflake’s documentation, has two parts:

A data share — which Data 360 objects you want to make available.
A data share target — the receiving account, such as your Snowflake account.

Link the two, and the shared objects appear on the other side. In Snowflake, they show up as a data product you can mount.

One limitation worth knowing: you can’t share an external data lake object, or a data model object mapped to one. In other words, you can’t federate data in and then share it straight back out.

Example scenarios

Unified profiles and a lifetime-value calculated insight shared to Snowflake for the finance team’s BI reports.
The data science team trains a churn model in Databricks on shared Data 360 engagement data — and the scores come back in through federation.

Data Cloud zero copy options side by side

Here’s how the three “data in” options compare:

	Live query	Caching	File federation
Stored in Data 360?	No	Yes, a cached copy	No
Where the work runs	Your warehouse	Data 360	Data 360, reading files
Freshness	Real time	Last refresh (15 min — 7 days)	As current as the files
Data 360 credits (quoted)	70 per million rows retrieved	2,000 per million rows cached	Same as live query; ~0 in the same region
Cost on your side	Warehouse compute per query	External storage	None on the lake
Best for	Fresh data, occasional use	Read often, changes rarely	Large lake data, same region

The credit figures are the ones quoted in Salesforce’s Four lessons from implementing zero copy blog. Treat them as indicative, and check the credit consumption help article and your own contract before you build a business case.

So what does it actually cost?

The biggest surprise for most teams is that Data Cloud zero copy can cost money in two places: Data 360 credits, and your warehouse bill.

Salesforce’s architects’ guide has two examples that show why the “right” option depends on how the data is used:

Caching wins: a dashboard on 1M records, with ~10K changes a day, viewed 20 times a day – about 600 credits a month with acceleration vs ~4,200 with live queries.
Live query wins: a segment published 20 times a day, on data that changes every 30 minutes – about 4,200 credits a month with live queries vs ~28,800 with acceleration.

Same platform. Very different answers.

The rule of thumb from the guide: if data is “accessed frequently but changes infrequently”, acceleration is typically more cost-effective.

So what should we actually take away from all this?

For me, the biggest takeaway is this:

“We’re using zero copy” isn’t really a useful statement.

Which zero copy? For which data? Read how often?

When you’re designing a Data Cloud zero copy setup, I’d ask five questions.

Which zero copy option fits? A quick decision flow

1. Which way is the data going?

Into Data 360? That’s federation. Out to Snowflake or Databricks? That’s sharing.

2. Is this core data, or everything else?

Salesforce’s guidance is to ingest critical data for canonical data models and core governance, and use zero copy for everything else.

3. How fresh does it need to be?

Minutes matter → live query. Yesterday’s data is fine → caching or file federation.

4. How often will it be read?

Read constantly but rarely changing → caching. Changing constantly → live query.

5. Where does it live, and who governs it?

Same-region object storage makes file federation very attractive. Avoid cross-region access unless you really need it.

And remember that with federation, a lot of the security lives in the source. Salesforce recommends row-level security and masking policies directly in the federated systems. As the blog puts it: “Permissions and governance are not details; they form the backbone of the entire model.”

The bigger picture

I think Data 360 zero copy is one of the most useful things about the platform.

And honestly, the fact that there are four options is a good thing.

But we need to be a bit more precise in how we talk about it.

Instead of asking:

Should we use zero copy?”

I’d ask:

Which way is the data going, how fresh does it need to be, how often will we read it, and where does it live?”

That’s a much more useful conversation.

Because, as we’ve seen, Data Cloud zero copy doesn’t mean zero movement — and it definitely doesn’t mean zero cost.

It means choosing where the work happens, and who pays for it.

So the next time someone says, “Let’s just use zero copy”, you know what to ask:

“Well… which zero copy are we talking about?”

If you’re curious how Data 360 data feeds the new AI features in Marketing Cloud, check out my recent post on smart features in the new Marketing Cloud Next.

October 13, 2026