What is Salesforce?
Most people meet Salesforce sideways. A new job turns out to run on it, a project lands on your desk with “the Salesforce team” attached, or someone asks whether a request is “just a quick change in Salesforce”. The name gets used for a lot of different things at once: a product you buy, a platform you build on, a company, and a whole ecosystem of jobs and certifications.
That vagueness is worth clearing up before you open Setup for the first time, because it shapes what you expect the platform to do and where you look when something surprises you.
This chapter answers the basics in plain language: what Salesforce actually is, why organisations run on it, what the main product families are, and who does the work. Everything after this gets more hands-on.
🔍 What Salesforce Actually Is
Section titled “🔍 What Salesforce Actually Is”Salesforce started in 1999, when Marc Benioff, Parker Harris, Frank Dominguez, and Dave Moellenhoff began building sales automation software delivered over the internet rather than installed on company servers. That delivery model was the genuinely novel part at the time, and it is still the thing most people mean when they call Salesforce a cloud company. The product range has grown enormously since, but the shape of the idea has not changed.
It helps to think of Salesforce as two things at once.
The first is a set of business applications you can buy and configure: tools for sales teams, customer service, marketing, and more. The second is Salesforce Platform, a foundation for storing data, controlling access, automating work, reporting, integrating systems, and building your own applications.
Salesforce Platform is what sets Salesforce apart from a typical off-the-shelf product. Many core CRM applications run on this shared foundation, so their records, permissions, automation, reports, APIs, and custom applications can work together. Organisations can also build on that foundation rather than only configure a finished product, which is why roles such as Salesforce Developer exist.
Not every Salesforce product is built on the same foundation. Some products in the wider portfolio have their own environments and data models. They can integrate with Salesforce Platform, but sharing the Salesforce name does not mean they work the same way underneath.
Because Salesforce runs in the cloud, people can use it wherever their organisation allows. The organisation does not download and install each new version: Salesforce applies platform upgrades automatically. The core platform receives three major releases each year, and some Salesforce products receive smaller updates in between.
The upgrade is automatic, but preparing for it is still the organisation’s responsibility. A release can add features, change parts of the interface, or affect something the team has already configured. Admins and developers therefore review what is changing and test important business processes around each release. Later chapters return to that routine when it becomes relevant.
📈 Why Organisations Run On It
Section titled “📈 Why Organisations Run On It”The practical appeal is that Salesforce can bring customer data, business processes, and user access into a governed system. Teams using applications on the core platform can work from the same records and workflows. Through integration and shared data design, products with separate environments can contribute too, extending that connected customer view beyond the core platform.
A connected system makes everyday hand-offs easier. A sales rep can update a customer record, automation can assign the next task, and a service agent can see the history without asking the customer to explain it again. Because those actions use the same data and access rules, reports can show what is happening across the whole process instead of only one part of it.
Salesforce can also change with the organisation. Admins can adapt fields, screens, automation, and reports as processes evolve. Developers can add custom applications or connect other systems when the standard features are not enough. This gives an organisation room to begin with a focused need and expand the system over time.
Salesforce is most valuable when the organisation pairs that flexibility with a shared understanding of what its data means, clear ownership of processes, appropriate access, and a safe way to introduce change. Those choices help people trust the system and make it easier to extend over time. This series teaches that judgement alongside the platform itself.
🧩 The Main Product Families
Section titled “🧩 The Main Product Families”Salesforce is sold as a family of products rather than one monolithic application. The ones you will hear about most often are Sales Cloud for sales processes, Service Cloud for customer support, Marketing Cloud Engagement for campaigns and journeys, Experience Cloud for portals and sites, and Commerce Cloud for e-commerce. Alongside those sit Industry Clouds, which package data models and workflows for specific sectors such as financial services or health.
Expect to meet most of those under two names. Salesforce has renamed several products under its Agentforce branding: Sales Cloud is now Agentforce Sales, Service Cloud is Agentforce Service, and Commerce Cloud is Agentforce Commerce. The older names remain in wide use in teams, job adverts, and learning material, so you will hear both for the same thing. This page sticks with the familiar names, because those are still the ones most likely to be handed to you. It is confusing rather than complicated.
The more useful boundary is that these products do not all run on one technical foundation. Sales Cloud, Service Cloud, Experience Cloud, and many Industry offerings use Salesforce Platform, so knowledge of objects, fields, permissions, and automation transfers directly between them. Marketing Cloud Engagement has its own environment and data model, and Commerce Cloud is itself split: the B2B side sits on the core platform, while B2C Commerce runs in its own commerce realms rather than in a Salesforce org. Each of those can integrate with the core platform, but product-specific knowledge still matters on either side of the boundary.
You do not need to pick one now. Most people meet whichever product their organisation already runs and broaden from there.
👤 Who Does the Work
Section titled “👤 Who Does the Work”Salesforce work is usually split across a few recognisable roles, and knowing which one you are heading towards makes the rest of this series much easier to navigate.
Administrators own the running org: who has access to what, whether the data can be trusted, the reports people make decisions from, and automation built by configuration rather than code. Developers step in when configuration runs out of road, writing Apex, building the interfaces configuration cannot produce, and connecting Salesforce to the other systems a business runs on. Architects decide how those pieces should fit together across systems, data, and security, which is why the role usually follows years spent in one of the other two.
In practice the boundaries are blurrier than the job titles suggest, particularly in smaller teams where one person does all three. Consultants, business analysts, and specialists round out the ecosystem.
🧭 How to Start Learning
Section titled “🧭 How to Start Learning”Two things make more difference than anything else early on: getting your own practice environment, and doing rather than reading.
Trailhead is Salesforce’s own free learning platform, built around short hands-on modules you complete in a real practice org. It is genuinely good, and it is the fastest way to get from “I have read about objects” to “I have made one”. This series links to specific Trailhead modules where they teach a mechanic better than prose can, and adds the judgement about when and why to use it that a tutorial usually leaves out.
Certifications exist for each role and can be worth pursuing, but they work best alongside real practice rather than instead of it. The role guides cover what each credential involves and when it is worth your time.
🧾 Terms You Will Meet Early
Section titled “🧾 Terms You Will Meet Early”Salesforce vocabulary tends to arrive before the explanation does, usually in a meeting where everyone else already knows it. These are the terms worth recognising now. Each one gets a rough gloss and a pointer to the chapter that covers it properly, so this is somewhere to look when a word turns up before you have reached it, not a substitute for those chapters.
| Term | Roughly what it means | Covered in |
|---|---|---|
| Org | An organisation’s own Salesforce environment, with its own users, data, and configuration | Platform |
| Edition | The tier an organisation buys, which sets the features and limits it gets | Platform |
| Sandbox | A copy of an org for building and testing changes without touching production | Platform |
| Setup | The area of Salesforce where an org is configured | Platform |
| Lightning Experience | The current Salesforce interface, as opposed to the older Salesforce Classic | Platform |
| Object | A type of record, such as Account or Contact; much like a table in a database | Data Model |
| Record | A single entry: one particular account, one particular case; much like a row in a database | Data Model |
| Field | One piece of information on a record, such as an email address; much like a column in a database | Data Model |
| Profile and permission set | The two things that decide what a user can see and do | Users |
| Organization-Wide Defaults (OWD) | The baseline record access everyone starts with, before sharing rules widen it | Record Access |
| Role | A user’s place in the role hierarchy, which widens which records they see rather than what they can do | Record Access |
| Flow | Salesforce’s tool for building automation without writing code | Customisation & Automation |
| Apex | Salesforce’s own programming language, for the work configuration cannot do | Apex Basics |
| SOQL | The query language for reading records out of Salesforce | SOQL Fundamentals |
| LWC | Lightning Web Components, the current framework for building custom Salesforce interfaces | Lightning Web Components |
🎯 Final Thoughts
Section titled “🎯 Final Thoughts”The useful thing to take from this chapter is not a definition but a question: which Salesforce does someone mean? The company, one of its products, the platform that several of those products share, or one organisation’s own org. Most early confusion comes from that ambiguity rather than from the technology itself.
The boundary that matters most is the technical one. Where a product runs on Salesforce Platform, what you learn about objects, permissions, and automation travels with you. Where it does not, you are learning a related system that happens to share a brand. Everything from here on assumes you can tell those two situations apart.
🚀 Next steps
Section titled “🚀 Next steps”Continue with How the Salesforce Platform Works, which covers editions, environments, licences, and how to find your way around Setup and the Lightning Experience interface.
If you would rather see the whole route first, both the Salesforce Admin Journey and the Salesforce Developer Journey map out where these chapters lead.