The test that sorts them: ask whether it has its own login page. If a “cloud” is something switched on inside the org you already have &mdash. A licence, a few standard objects, a permission set &mdash. Then it is packaging, and moving between those clouds is a procurement conversation rather than a migration. If it has a separate login, a separate data model and a separate admin console, it is a different product that Salesforce built or bought elsewhere and sells under the same brand. Sales, Service, Revenue, Field Service, Net Zero and Experience sit on the first side of that line. Marketing Cloud Engagement, B2C Commerce and Heroku sit on the second.
The official list is shorter than the folklore
Salesforce’s own products page names Agentforce, Data 360, Salesforce Platform, Sales Cloud, Revenue Cloud, Service Cloud, Field Service and Operations, Marketing Cloud, Commerce Cloud, Tableau, MuleSoft, Slack, Net Zero Cloud and Heroku. That is the catalogue. Health Cloud, Financial Services Cloud and the rest of the industry products do not appear on it as separate clouds &mdash. They are industry solutions layered onto the same platform, which is exactly why they behave like managed packages once installed.
The names are mid-rebrand, and Salesforce’s own pages disagree
One rename is settled. Salesforce’s data platform page states it without hedging: “Salesforce Data 360 is the official new name for what was previously called Data Cloud.” The product did not move underneath the label &mdash. Same platform, same capabilities. The architect decision guides have followed, and now ship Data 360 Provisioning and Data 360 Interoperability guides under those names. If a doc search returns nothing, search the new name.
The rest of the rebrand is halfway done, and this is the part worth knowing before you write a proposal. Checking Salesforce’s own properties on 22 September 2026 returned genuinely conflicting answers:
| Old name | Agentforce-era name | What the vendor’s pages actually show |
|---|---|---|
| Data Cloud | Data 360 | Confirmed in plain words on the product page |
| Service Cloud | Agentforce Service | Help documentation is titled Agentforce Service; the announcement post says “Formerly known as Service Cloud”. The product guide still leads with Service Cloud |
| Sales Cloud | Agentforce Sales | Both names in use on the same page. Sales Cloud is still the headline |
| Salesforce Platform | Agentforce 360 Platform | Search results carry the new title; the page itself still says Salesforce Platform |
Meanwhile the products index still lists Sales Cloud, Service Cloud and Salesforce Platform under their original names. So on the same day, on the same domain, Salesforce calls Service Cloud two different things depending on which page you land on.
Treat this as a live inconsistency rather than a fact to memorise. The practical rule: in anything contractual, write both names the first time — “Service Cloud (Agentforce Service)” &mdash. And search both when hunting documentation. Our existing walkthrough still sits at Data Cloud, for Salesforce people, and the mechanics in it are unchanged by the label.
A related snag if you research this yourself: help.salesforce.com returns a navigation shell to anything that is not a browser, so the Help articles cannot be verified by fetching them and a status code proves nothing. The Help titles above were read from search metadata, and Help documents are cited here by name rather than linked for that reason.
Which side of the line each one sits on
| Product | Where it runs | What you are actually buying |
|---|---|---|
| Sales Cloud | Your org | User licences plus Lead, Opportunity, Quote, Forecast |
| Service Cloud | Your org | User licences plus Case, Entitlement, the console |
| Revenue Cloud | Your org | User licences plus the quoting and billing object set |
| Field Service | Your org, plus a mobile app | A managed package and its own licence types |
| Experience Cloud | Your org | External-user licences against the same records |
| Net Zero Cloud | Your org | A managed package and a licence |
| Salesforce Platform | Your org | A cheaper user licence with the CRM objects removed |
| Data 360 | Connected platform | Consumption credits, billed on usage |
| Marketing Cloud Engagement | Separate platform | A separate tenant with its own login |
| Commerce Cloud (B2C) | Separate platform | A storefront platform with its own tooling |
| Tableau, MuleSoft, Slack, Heroku | Separate products | Their own accounts and billing |
What actually changes when you “add a cloud”
For everything in the top half of that table, almost nothing changes structurally. Your org is one org. There is one Account record, one sharing model, one set of automation. What a user can reach is decided by their user licence type first and by permission sets second &mdash. The licence sets the ceiling, and no permission set can grant access above it. Salesforce Help documents this under User License Types. The behaviour is the ordinary object permission versus record access split you already work with.
This is why “we’re on Sales Cloud, can we start doing cases?” is a purchasing question rather than an implementation project. The Case object is already in your org’s schema. Your users cannot see it because their licence does not include it.
The Salesforce Platform licence is the cleanest demonstration: same org, same data, same automation, with the CRM objects removed from the licence. Nothing was installed or uninstalled to make that true.
Marketing is the boundary that is currently moving
Marketing Cloud Engagement is the classic example of a genuinely separate platform: its own login, its own data extensions, its own send infrastructure, reached from your org through an integration rather than a report type.
That is changing. Salesforce’s marketing page now leads with Marketing Cloud Next, described as “built natively on the Salesforce platform with AI, Data 360, and Agentforce at its core.” The boundary is being pulled inward while Engagement and Account Engagement continue alongside it. If you are scoping marketing work in 2026, which of the three you are on changes nearly every integration answer, and the product name alone will not tell you.
Commerce carries the same split. Salesforce’s commerce page notes that Demandware, acquired in 2016, “is now a part of Commerce Cloud” &mdash. B2C Commerce still carries that separate-platform heritage, while B2B Commerce and Order Management sit much closer to the core.
Where the distinction actually bites
Reporting stops at the boundary. Report types read your org’s objects. Sends that happened in a Marketing Cloud Engagement tenant are not in your report builder unless something deliberately moved that data across. Teams discover this when the first cross-channel attribution question arrives.
Sandboxes only copy the org. A refresh gives you a copy of your org and nothing beyond it. Marketing Cloud Engagement does not offer a standalone sandbox at all &mdash. Salesforce Help points you at a separate Business Unit for testing instead &mdash. So any plan that assumes “refresh the sandbox and we have a full environment” breaks the moment a second platform is in scope. Read it next to our sandbox strategy notes.
Permission design stacks per cloud, not per user. Every cloud you switch on brings its own permission sets, and they accumulate on the same users. This is the ordinary argument for permission set groups and muting rather than granting each set individually, and it gets more acute with each cloud added.
Org-wide limits are shared. Custom object and field allocations belong to the org, not to a cloud. Each managed-package cloud you install spends from the same allocation &mdash. Check yours on the object limits page before assuming there is room.
What I would establish before signing
Ask two questions of anyone selling you a cloud. Does this create a separate login? That answer alone tells you whether you are buying a feature set or taking on a second platform to administer, staff and integrate. And is it licence-priced per user or consumption-priced? Data 360 is credits, and consumption pricing fails differently &mdash. The bill follows your design rather than your headcount, the same trap described in our Agentforce cost model piece.
Two caveats, stated plainly. The licence boundaries here are mapped from Salesforce’s current product and architecture documentation, not from an org where all of these were provisioned side by side and tested against each other. And the naming table is a snapshot of a rebrand still in progress on 22 September 2026 &mdash. It will drift, and the fact that it is inconsistent is more durable than any individual row. Where either decides a budget or a delivery plan, confirm it against your own contract.
Frequently asked
Is Salesforce Platform a cloud? It is on the official product list, but it is better understood as a licence tier than a product. Same org, same platform, CRM objects removed. It is what you buy for users who need custom apps and not the sales or service functionality.
Can one org run Sales, Service and Experience Cloud at once? Yes, and most mature orgs do. They share the Account, Contact and sharing model. What accumulates is permission complexity, not data duplication &mdash. See Experience Cloud licence types for how external users fit the same records.
Are Health Cloud and Financial Services Cloud separate clouds? They did not appear as separate products on the page I checked. In practice they behave as industry solutions installed onto the platform, which means their objects count against your org’s allocations like any other package.
Does adding a cloud require a new org? For anything in the top half of the table, no &mdash. That is the point of the distinction. For Marketing Cloud Engagement or B2C Commerce you are provisioning a separate platform, which is closer to onboarding a second vendor than to enabling a feature.
Should I still say Data Cloud, or Service Cloud? Data Cloud is settled &mdash. Say Data 360, because the documentation has moved and searching the old name will increasingly miss current material. Service Cloud is not settled, so say both until Salesforce picks one.
Reference: Salesforce product, data, marketing, commerce, sales and platform pages and the Architect decision guides, all checked 22 September 2026; Salesforce Help “User License Types” and the Agentforce Service documentation, cited by name because help.salesforce.com cannot be verified by fetch.
