Salesforce Product Families: Clouds and Platform
“Salesforce” is not one application. It is a family of products sold separately. Some are built on the core Salesforce Platform; others have their own environments and connect to it through integration. Many organisations combine several products, but the right mix depends on the work they need to support.
Knowing which is which saves a surprising amount of confusion early on, because product boundaries decide who you talk to, which licence covers what, and which documentation actually applies to the problem in front of you.
This page is a practical map of the product families covered in this series, not a complete catalogue of everything Salesforce sells. Each family below has its own guide with the practical detail; this is the orientation that makes those guides easier to place.
🧩 The Main Product Families
Section titled “🧩 The Main Product Families”Start with this diagram as a rough map of those families. It places them around Salesforce and includes Data 360 and Analytics because you will often see them discussed alongside the products. They work across several products rather than forming product families of their own, so we will return to them in What Cuts Across Them.
The diagram gives you the shape of the portfolio, but there is one naming complication to understand before looking at the families more closely: Salesforce has renamed several products under the Agentforce banner. Sales Cloud is now Agentforce Sales, Service Cloud is now Agentforce Service, and Commerce Cloud is now Agentforce Commerce. The older names remain in wide use across teams, job adverts, Trailhead content, and parts of the product interface, so you will hear both names for the same product.
Marketing is the exception to that pattern. Agentforce Marketing is another name for Marketing Cloud Next, not a new name for Marketing Cloud Engagement.
In practice, each product family has a different centre of gravity:
Sales Cloud (Agentforce Sales) supports the work of finding and winning customers. Leads can become accounts, contacts, and opportunities, while activities, pipeline views, and forecasts give the sales team a shared picture of what is happening and what needs attention next.
Service Cloud (Agentforce Service) supports the work that happens when customers need help. Cases provide the main record of that work, with routing, communication channels, knowledge, entitlements, and agent workspaces helping teams respond consistently and keep the service history together.
Commerce Cloud (Agentforce Commerce) covers digital storefronts and the journey from browsing to buying and managing an order. Its B2B and B2C offerings do not share the same technical architecture, so knowing which one you have is an important first step before you design or build anything.
Marketing Cloud Engagement (formerly Marketing Cloud) coordinates customer communications across email, mobile messaging, and automated journeys. It has its own environment and data model, which makes data movement, customer consent, and the connection back to Salesforce Platform central parts of the design.
Experience Cloud extends selected Salesforce data and processes to people outside the main internal application. It is commonly used for customer self-service, partner collaboration, and employee sites, with identity, licences, and sharing rules deciding what each audience can see and do.
Industry Clouds add data models, processes, and capabilities shaped around sectors such as healthcare, financial services, manufacturing, and the public sector. They give a project a more relevant starting point, while still needing configuration and governance to fit the organisation using them.
Marketing is the messiest corner of the naming picture. Marketing Cloud Engagement is the long-standing product with its own environment. Marketing Cloud Next, also called Agentforce Marketing, is the newer product built on Salesforce Platform. They use different APIs that are not compatible with each other. If you are choosing rather than inheriting, confirm which one a proposal actually refers to before committing.
🧱 Which Products Share the Platform
Section titled “🧱 Which Products Share the Platform”This is the boundary the rest of the page keeps referring to, and it is not something the names tell you. Products built on Salesforce Platform live inside your org and share its underlying model: Salesforce objects and fields, the permissions and sharing framework, automation such as Flow and Apex, and administration through Setup. That does not mean every product has identical objects, licences, or tools; each one can add its own data model and capabilities. Products outside the platform run in a separate environment and connect to your org through integration.
| Product | Where it runs |
|---|---|
| Sales Cloud | Your Salesforce org, on Salesforce Platform |
| Service Cloud | Your Salesforce org, on Salesforce Platform |
| Experience Cloud | Your Salesforce org, on Salesforce Platform |
| Industry Clouds | Mostly your Salesforce org, on Salesforce Platform |
| B2B Commerce | Your Salesforce org, on Salesforce Platform |
| B2C Commerce | Its own commerce realms, separate from your org |
| Marketing Cloud Next (Agentforce Marketing) | Your Salesforce org, on Salesforce Platform |
| Marketing Cloud Engagement | Its own environment, with its own tenant and user model |
For anything not on that list, where you log in and configure it gives you a useful clue, but not a final answer. A product configured through your org’s Setup menu and working directly with Salesforce records is likely to be on the platform. A product with its own login, admin console, and idea of what a contact is is more likely to be a separate system. Confirm the current product documentation and your organisation’s contract before assuming that familiar objects, licences, or APIs carry across.
🔗 What Cuts Across Them
Section titled “🔗 What Cuts Across Them”Some parts of the portfolio cut across product boundaries rather than fitting neatly alongside the product families above.
🔄 Data 360
Section titled “🔄 Data 360”Data 360, formerly Data Cloud, connects data from Salesforce and other systems, maps it into a common model, and uses identity-resolution rules to bring related records into unified profiles. Those profiles, segments, and calculated insights can then be used in sales, service, marketing, commerce, automation, and analytics.
That makes Data 360 useful when the same customer appears differently across several systems and teams need a more complete view. It does not replace those source systems or remove the need for good data rules: an organisation still has to decide which records belong together, what people have consented to, and where the combined data may be used.
🤖 Agentforce
Section titled “🤖 Agentforce”Agentforce is Salesforce’s platform for AI agents that can answer questions and carry out defined tasks. An agent’s capabilities are divided into subagents (previously called topics) with instructions that guide decisions and actions that can retrieve information or perform work through tools such as Flow, Apex, and integrations.
Agentforce can work across sales, service, marketing, commerce, and other areas, which is why the name now appears in several product families. That does not make it one commercial package: Salesforce offers consumption-based pricing, per-user licences, product add-ons, and Agentforce 1 Editions.
Agents do not get unrestricted access to Salesforce. Depending on the type, an agent’s access is controlled by either the permissions of the person using it or those of a dedicated agent user. You also choose which actions it can take. The practical rule is simple: test what an agent can see and do before people rely on it.
📊 Analytics
Section titled “📊 Analytics”Analytics starts with the reports and dashboards built into Salesforce Platform. They answer many day-to-day operational questions using Salesforce records, such as which opportunities are due to close this quarter or how many cases are waiting in each queue.
CRM Analytics adds more interactive analysis, can combine Salesforce and external data, and puts insights into the flow of work. Tableau serves broader business-intelligence needs across many data sources and audiences. The right starting point depends on the question, where the data lives, and who needs to explore it; not every reporting requirement needs a separate analytics product.
These move faster than the core products and their positioning changes between releases, so treat any description of them (including this one) as something to confirm against current Salesforce material before you rely on it in a decision.
🧭 How the Mix Shapes Your Work
Section titled “🧭 How the Mix Shapes Your Work”Which products your organisation runs is not a background detail. It shapes what your job actually involves day to day.
Products built on Salesforce Platform share a recognisable model of objects, fields, permissions, automation, reporting, and APIs. An admin in a Service Cloud org spends time on case routing, entitlements, and Omni-Channel; an admin in a Sales Cloud org spends it on pipeline, forecasting, and territories. The core skills transfer, even though the surface changes.
Adjacent products do not automatically inherit that model. Marketing Cloud Engagement uses its own accounts, business units, data extensions, permissions, and automation tools. B2C Commerce runs in commerce realms rather than Salesforce orgs. Your platform foundation still helps you understand how these systems connect, but it does not replace product-specific learning.
The same is true with code. Each product has its own data model and integration points, and building across two of them means understanding how they meet, which is usually where the interesting problems live.
Sales Cloud and Service Cloud are common places to begin, and people broaden as projects demand it. Some specialise deliberately: Commerce for retail work, Health Cloud for healthcare, Financial Services Cloud for banking and insurance. Both routes are normal.
🎯 Final Thoughts
Section titled “🎯 Final Thoughts”The question worth carrying away is not what each product does, but where its boundaries sit. Ask whether it runs on Salesforce Platform or in an environment of its own, and ask what the licence actually covers. Those two answers decide whether your objects, permissions, and platform skills travel with you, or whether you are starting much closer to scratch.
Names are the least reliable guide to that. Agentforce branding cuts across the product families rather than mapping neatly onto them, and old and new names remain in circulation side by side, including on Salesforce’s own site. Check the boundary rather than the label.
🚀 Next steps
Section titled “🚀 Next steps”Pick the product your organisation runs and start there. Sales Cloud and Service Cloud are common starting points.
If you are earlier than that and still building the platform foundations underneath these products, What is Salesforce? and How the Salesforce Platform Works come first.