Salesforce Data Cloud pricing runs on a credit meter. Size the commitment to measured burn.

Salesforce Data Cloud, now sold as Data 360, is priced in credits consumed as you ingest, unify, segment and activate data. Unification usually burns the most, and the safest commitment is one sized from a measured pilot.

How is Salesforce Data Cloud licensed and priced?

Salesforce Data Cloud is licensed by consumption. You buy a pool of credits, and the platform draws it down each time it ingests, unifies, segments or activates data, with each action type consuming at its own rate. User counts do not drive the bill, which is why Data Cloud behaves so differently from seat products like Sales Cloud.

Salesforce now sells the product as Data 360. On its current price list, Flex Credits cost $500 per 100,000, or half a cent each. There are also profile based plans: Profiles at $240 per 1,000 profiles a year with 1 Flex Credit per profile, and Enterprise Profiles at $420 per 1,000 with 2 credits per profile.

Which Data Cloud actions consume credits?

The current price list treats batch ingestion and zero copy integrations as free. Credits are consumed by the work done on the data once it is available to the platform:

• Unification. Identity resolution, charged per million source rows processed by your match and reconciliation rules.
• Streaming and real time pipelines. Data that arrives continuously instead of in scheduled batches.
• Segmentation and activation. Building audiences and pushing them to downstream targets such as Marketing Cloud or ad platforms.
• Preparation, queries and sharing. Transforms, reading data back out, and sharing it with other platforms.
• AI grounding. Agentforce and other Data Cloud powered AI draw on the same pool when they retrieve data. Our Agentforce guide covers that interaction, and the AI credits consumption model explains how the two meters relate.

Unifying a million rows costs 1,500 times as much as segmenting a million rows. That gap is why identity resolution tends to dominate any org that runs it across many sources.

How do the volume tiers and sandbox rates work?

Production multipliers step down in four tiers as monthly consumption of each usage type grows. The base tier covers the first 300,000 credits, the second runs to 1.5 million, the third to 12.5 million, and the fourth applies beyond that. Unification falls from 75,000 credits per million rows at the base tier to 15,000 at the top.

The tiers reset on the first day of each calendar month and are counted per usage type, so heavy segmentation does nothing for your unification rate. Sandbox usage bills at a flat 80 percent of the base multiplier with no tiers. Unused Flex Credits expire at the order end date, with no rollover.

What consumes the most Data Cloud credits?

Profile unification is usually the heaviest line. Buyers tend to expect storage to dominate, and it does not. The table shows how the four main action types split across the active orgs in our engagements, and what each one scales with.

Why does identity resolution grow faster than the other lines?

Unification work grows with both record volume and source count, and it sits at the center of Salesforce's unified data and AI direction. Each new system adds rows to match and duplicates to reconcile, so an org that connects two more systems in year two finds its heaviest line has grown with no change to the order form.

Unification also depends on the quality of your source data, which no license term controls. Duplicate contacts, inconsistent email formats and stale records all force more resolution work. Cleaning data before ingestion cuts the consumption itself, which no negotiated rate can do.

Why does segmentation cost depend on refresh cadence?

Segmentation grows with how often audiences refresh, more than with how many audiences exist. A handful of audiences refreshed hourly can outweigh many refreshed daily. The cadence is usually set once, by whoever built the first segment, and rarely reviewed after that.

Why is ingestion so often oversized?

Ingestion grows with connected volume. Teams often connect every available source for completeness, then pay to bring in and process data that no segment ever touches.

Our ingestion figures come from 2024 and 2025 contracts, when batch pipelines were still metered. On the current Flex Credits price list batch ingestion is free, so on new contracts the ingestion share sits mainly in streaming and real time pipelines.

What does a monthly Data Cloud bill look like?

A mid sized marketing org can spend about $4,000 a month at list, with identity resolution close to half of it.

Say you stream 80 million web and app events a month, batch load three other systems, and run identity resolution over 5 million source rows. You refresh 20 segments of 5 million profiles daily, activate 2 million rows a day to three targets, and query 500 million rows.

Over 12 months that is about 9.6 million credits, or $48,138 at list before any discount. Unification accounts for about 45 percent of the bill while processing the fewest rows of any metered line.

The table counts each segment refresh as 5 million rows processed. In practice the count depends on the objects each segment scans, so read the row counts from your own org.

What happens if four segments switch to hourly refresh?

Say marketing switches 4 of the 20 segments to hourly refresh. Those 4 now process 14.4 billion rows a month, against 2.4 billion for the other 16 combined. Segmentation jumps from 150,000 credits to 732,000, even after the second tier discount, and the monthly bill rises from $4,011.50 to $6,921.50.

That is a 73 percent increase from one setting that finance does not see. Changes like this, made after signature, are how a bill drifts above the estimate behind the commitment.

What happens when two more systems connect in year two?

Say two new systems add 3 million source rows to identity resolution. Unification rises from 360,000 credits to 540,000 a month. That is an extra $900 a month, or $10,800 a year, before anyone builds a segment or activation on the new data.

What have we seen in recent Data Cloud negotiations?

We ran roughly 25 Data Cloud licensing engagements across 2024 and 2025, and the credit model surprised almost every buyer. The meter runs on actions buyers do not watch, and it behaves unlike anything else on their Salesforce contract. Three patterns recurred:

• Burn above estimate. Once ingestion and segmentation went live in production, actual credit consumption ran 1.3 to 2.0 times the initial estimate, with a median of 1.6 times.
• Unification as the largest line. Profile unification and identity resolution drove the biggest share of burn on active orgs, in the range shown in the table above.
• Smaller pools after a pilot. Buyers who sized credits to measured workloads cut the committed pool 15 to 35 percent against the vendor estimate, with a median cut of 24 percent.

The first and third findings can look contradictory. As we read them, overruns happened where the commitment rested on a forecast and the workload then grew unmanaged; smaller pools came where the buyer piloted, tuned the workload and sized from the meter.

A smaller commitment with a clean usage baseline beats a large one built on a forecast that no one can check twelve months later.

Why we advise against buying a generous pool for the better unit rate

The standard advice is to buy a generous pool up front, because committed credits carry a better unit rate than overage. That only works if the estimate behind the commitment is sound, and in most of our engagements it was guesswork. Buyers either overcommitted to credits they never burned or locked a rate against the wrong workload mix.

Every credit still unburned at the order end date is lost. Commit to what a pilot measured plus the growth you have approved projects for, and secure the right to buy more at the committed rate.

Why does the overage rate deserve as much attention as the committed rate?

Consumption above the committed pool bills at a higher rate. That makes a sizing error expensive in both directions: overcommit and you pay for credits you never burn, undercommit and the excess bills at a premium. An undersized pool can end up costing more than a correctly sized one.

Treat the published overage rate as an opening position. Cap it in the order form, ideally at the committed rate, instead of accepting it as a default.

How should you size a Data Cloud credit commitment?

Size it from a bounded pilot on real workloads, with credit burn recorded by action type. The conversation with Salesforce then starts from what the meter recorded, and their sizing model becomes something to test against it. A pilot we would size from has four features:

1. Representative sources. It uses the systems that will feed identity resolution in production, at realistic row counts, after the cleanup you plan to do anyway.
2. At least one full calendar month. Billing runs monthly and the tiers reset on the first, so a partial month misstates what a steady month costs.
3. Production rates. If it runs in a sandbox, convert the results, since sandbox multipliers are 80 percent of the production base rate and carry no tiers.
4. Real refresh schedules. Segments refresh on the cadence marketing actually wants, so the pilot captures the cost of that choice.

How do you check your own Data Cloud consumption?

Salesforce's Digital Wallet gives a near real time view of consumption for Data Cloud and the other credit products, broken down by usage type. Record that view weekly during the pilot, so you can see how each line changes as sources go live.

Then match each usage type to its driver: rows reaching identity resolution for unification, refresh schedules for segmentation, and event volumes for streaming. If a line jumps and you cannot name the driver, find it before the pilot ends.

What changes if unification, ingestion or segmentation dominates?

• Unification led. Work on data quality and on which sources feed the identity resolution ruleset. Negotiate hard on the rate hold, because this line grows with every system you add.
• Ingestion led. Disconnect sources added for completeness, move feeds that do not need to be live from streaming to batch, and check whether zero copy access can replace copying the data in.
• Segmentation led. Review refresh schedules segment by segment, and keep hourly refresh only where an activation depends on it.

What should the Data Cloud order form say?

The order form should cap the overage rate, hold the unit price for the whole term, and let the pool follow your measured ramp. These are the terms we ask for:

• Overage cap. Consumption above the pool bills at the committed rate or a stated ceiling, which turns an undersized pool into a manageable miss.
• Price hold on added credits. Credits bought mid term cost the same as the original pool, so you can commit small and add later without penalty.
• Annual ramp. The pool grows by year with your rollout plan, so you are not paying for year three volume from day one.
• Rate card fixed at signature. The multipliers in force when you sign apply for the term, and a later card applies only where it is cheaper. A change to the unification multiplier can shift your bill by more than any discount.
• Carry forward or reduction right. Standard terms allow no rollover, so ask for unused credits to carry into the renewal, or for the right to reduce the pool at renewal.
• Visible AI grounding. Agentforce draws on the same pool, so ask for its consumption to be reported as its own line.

What will the Salesforce account team say, and how should you answer?

• "Committed credits are cheaper, so buy for the full term now." Ask for the committed per credit rate to apply to any credits added during the term, then buy what the pilot supports.
• "Our sizing model is based on customers like you." Ask for the model's inputs by usage type, including rows reaching identity resolution, refresh cadence per segment and streaming volume. Compare each with your pilot.
• "Credits cannot roll over." Accept that as the standard term and answer with a ramp and a price hold, so less is stranded if adoption runs slower than planned.
• "Data Cloud is included in your edition." Ask how many credits are included, what your planned loads and AI grounding will consume, and what the overage rate is above that.

When is the best time to negotiate Data Cloud credits?

Salesforce's fiscal year ends on January 31, so its fourth quarter, November to January, is when account teams have the most room on price. Plan the pilot so measured burn is in hand before then. Our Salesforce renewal timeline sets out the months before signature.

Check which price book your quote references. Salesforce now markets the platform as Agentforce 360 and Data Cloud as Data 360, and Einstein 1 Edition, which bundled Data Cloud, has given way to the Agentforce editions on a higher price book. Keep Data Cloud credits as their own line, sized and capped. More guides sit in the Data Cloud hub.

What to do next

1. This month. Map the data sources you plan to connect and the actions each will trigger, because the action mix decides the bill.
2. Before the pilot. Clean and deduplicate the source data that will feed identity resolution.
3. During the pilot. Record credit burn by usage type in the Digital Wallet, and convert any sandbox figures to production rates.
4. At pilot end. Work out whether unification or ingestion dominates, and apply the matching fixes before you size anything.
5. Before signature. Size the pool to observed consumption, cap the overage rate and fix the rate card version in the order form.
6. After go live. Review refresh schedules and new source connections against the pool every quarter. The Salesforce practice can run the pilot read and the commitment with you.

Frequently asked questions