The Salesforce Platform and Its Clouds

This cursus assumes the CRM fundamentals: the data model of companies, people, leads, and deals, and the pipeline and adoption concepts. Salesforce is the market-leading expression of all of that, holding roughly 21 percent of the global CRM market and reporting around 37.9 billion dollars of revenue in its fiscal 2025, the largest CRM vendor by a clear margin. Learning it is one of the more direct routes into a technology career, because so many companies run it and so few people can configure it well.

But Salesforce is best understood as more than a CRM. It is a platform: a foundation on which the CRM apps are built, and on which companies build their own. That distinction shapes everything, and missing it is why beginners find Salesforce confusing.

This cursus covers the platform in three parts:

• This lesson: the platform itself, how it is architected, and the clouds built on it.
• Lesson 2: the data model, objects, fields, and relationships, Salesforce's specific expression of the CRM model.
• Lesson 3: automation, security, and the Salesforce career.

The key idea to carry from the start: Salesforce is something you configure, not primarily something you code. A huge share of what it can do is done by declaring it, pointing and clicking to define data structures, rules, and automation, rather than writing programs. Understanding why it works that way, which is the point of this lesson, is what makes the rest of the platform make sense.

Salesforce pioneered a model now standard in business software: multi-tenant, cloud-delivered software as a service. Both halves matter.

Cloud / SaaS. Salesforce runs on Salesforce's servers and you access it through a browser. There is nothing to install or maintain, no servers to run, no upgrades to apply. The vendor operates the software; you use it. This is why a small company can run enterprise-grade CRM without an IT department.

Multi-tenant. This is the deeper architectural choice. Rather than giving each customer their own separate copy of the software, Salesforce runs one shared system that serves all customers at once, like an apartment building where everyone has a private, secure home but shares the underlying structure and utilities. Every customer runs on the same core platform and the same infrastructure.

Multi-tenancy has consequences that explain much of how Salesforce behaves:

• Everyone gets upgrades together. Salesforce releases new features to all customers simultaneously (famously three times a year), because there is one shared platform to update, not thousands of separate installs.
• Your data is isolated but the platform is shared. Strict boundaries keep each customer's data private even though the system is common. This isolation is a core security guarantee.
• Resources are shared, so they must be governed. Because all customers draw on the same infrastructure, no single customer can be allowed to consume so much that it degrades the system for everyone. This is the origin of the governor limits that shape how you build on Salesforce, covered in Lesson 3, and it is not an arbitrary restriction, it is the direct, necessary consequence of sharing one platform among thousands of tenants.

So the architecture is not trivia. Multi-tenancy is why Salesforce upgrades everyone at once, why it is so configurable, and why it imposes limits, three facts that puzzle beginners until they see the shared-platform reason behind them.

The single most important idea for understanding Salesforce is metadata, and it explains why the platform is configured rather than coded.

Metadata means "data about data", the definitions of your setup rather than the records themselves. When you create a custom object, add a field, define a validation rule, or build an automation in Salesforce, you are not writing a program that Salesforce runs. You are creating metadata: a description of what you want, which the platform's engine then interprets and enacts.

An analogy: you do not build the machine, you fill in a form describing the machine you want, and Salesforce's engine builds and runs it for you. Your "customization" is a set of definitions the platform reads.

This metadata-driven design is the source of Salesforce's defining trait, that so much is done declaratively (by point-and-click configuration) rather than programmatically (by writing code):

• Speed. Defining a new object or field is a form to fill in, not software to write, test, and deploy. Business changes that would take an engineering team weeks can be configuration changes made in an afternoon.
• Accessibility. A Salesforce administrator, who need not be a programmer, can configure enormously powerful behavior. This is why "Salesforce admin" is a genuine no-code technology career (Lesson 3).
• Consistency and safety. Because you declare what you want and the platform handles how, on shared multi-tenant infrastructure, your configuration cannot easily break the underlying system.

The practical division to remember: on Salesforce, you configure declaratively by default, and write code only when configuration cannot express what you need. Salesforce's guidance is literally to prefer clicks over code. For a learner, this is liberating: most of the platform's power is reachable without programming, and understanding the metadata model, objects and fields and rules as definitions, is the key that unlocks it.

Everything a company has in Salesforce lives in its org (short for organization), a single, secure instance of the Salesforce platform belonging to that company. Understanding the org clarifies how Salesforce is structured and administered.

An org contains, together, all of a company's:

• Data: its records, the accounts, contacts, leads, opportunities, and everything else.
• Metadata: its configuration, the custom objects, fields, rules, automations, and page layouts that shape how the org works.
• Users: the people who log in, with their permissions.
• Customizations and installed apps: anything added on top.

The org is the boundary of a company's Salesforce world. Within it, everything is connected and shares configuration; outside it is another company's separate org. In the apartment-building analogy, your org is your apartment, private and yours to arrange, inside the shared building.

A practical detail that matters for the career: companies typically have not just one org but several, a production org (the live one the business uses) and one or more sandboxes (copies used to build and test changes safely before they go live). This mirrors ordinary software practice, you do not experiment on the live system, and it is why Salesforce work involves developing in a sandbox and then deploying the metadata to production.

The org is also the unit of administration. A Salesforce admin administers an org: its users, its data, its configuration. So when you hear "our Salesforce," it means "our org", one company's private, configured instance of the shared platform, and it is the thing an admin owns and shapes.

Salesforce's product names all end in "Cloud", Sales Cloud, Service Cloud, Marketing Cloud, and more, and beginners often think these are separate products. They are better understood as apps built on the one shared platform, each tailored to a different business function.

The main ones:

• Sales Cloud: the classic CRM for sales teams, the accounts, contacts, leads, opportunities, and pipeline of the fundamentals. When people say "Salesforce CRM," they usually mean this.
• Service Cloud: for customer support, built around Cases (support tickets) and the tools to resolve them, knowledge bases, queues, service consoles.
• Marketing Cloud: for marketing, email campaigns, journeys, and automation to nurture leads.
• Commerce Cloud, Experience Cloud, and others: for e-commerce, customer portals, and further functions, plus industry clouds tailored to healthcare, finance, and the like.

The unifying insight is that these are not separate systems bolted together, they are functional apps sharing one platform, one data model, and one org. Sales Cloud and Service Cloud both use the same Accounts and Contacts; a support Case in Service Cloud sits on the same customer record as a sales Opportunity in Sales Cloud. That shared foundation is exactly the collaborative-CRM benefit from the fundamentals, made architecture: because everything lives on one platform in one org, sales and service genuinely see the same customer.

So when a company "uses Salesforce," what they have is an org, on the shared multi-tenant platform, running one or more clouds (apps) against one common data model, all configured through metadata. That single sentence is the whole architecture, and it is the frame for the specific data model in Lesson 2.

Assemble the platform.

The through-line: Salesforce is a shared, metadata-driven platform that you configure, and the CRM clouds are apps on top of it. Almost every distinctive thing about Salesforce, its configurability, its three-times-a-year upgrades, its limits, its no-code admin career, its unified customer view across sales and service, traces back to that architecture.

For a learner, this frame is the unlock. Salesforce can feel like an ocean of features, but they all sit on this foundation: definitions (metadata) held in a company's instance (org) on a shared platform, arranged into apps (clouds), configured mostly by clicks. Hold that, and the specifics stop being arbitrary.

With the platform understood, the next question is the one the CRM fundamentals set up: how does Salesforce actually model customers? Its objects, fields, and relationships, the concrete data model, are Lesson 2, and they are where day-to-day Salesforce work begins.

One multi-tenant platform serves all customers; each company has a private org holding its data and metadata; the clouds are functional apps (Sales, Service, Marketing) sharing that org's single data model, and configuration is metadata the platform interprets rather than code.