Understand How Licenses Work

If you’ve been around Salesforce for a little while, you may have heard the analogy comparing Salesforce to a large office building, and customer orgs to tenants occupying offices in the building. Each org uses the shared Salesforce technology infrastructure and has secure, private operational space accessible only to its users.

Carrying that analogy further, a Salesforce license is similar to a lease agreement between a property manager and a tenant. A Salesforce license, or more precisely, a license definition, is a metadata description of the Salesforce features and services that are available to your org.

License definitions describe functionality for your org as a whole and for individual users in your org. A license itself is the specific agreement between Salesforce and a particular customer, which defines functionality for that customer org.

An org typically has multiple licenses that together comprise all its available features and services. An org’s licenses include information specific to the org, such as start and end dates, the number of users who can access Salesforce, the number of custom objects the org can create, and so on.

Later in this unit we explain more about the various types of licenses Salesforce provides and what functionality they control.

Provisioning is the process that Salesforce administers to activate your licenses and enable functionality in your org. When your org is provisioned, it’s like a tenant shaking hands with the property manager, making the initial lease payment, and getting the office keys. Once your org is provisioned, you can get to work with Salesforce! We explain more about upgrades and add-ons in the third unit. The automated provisioning process occurs when:

• You make an initial purchase to set up a Salesforce org.
• You purchase an upgrade or add-on.
• A Salesforce patch release includes changes to a license definition.

It’s worth noting that provisioning applies only to production orgs, which are active orgs where users access and work with live data. If you have one or more sandbox orgs (staging environments used for testing), you need to push any license changes to each sandbox org to keep the sandbox orgs in sync with your production org. You can update sandbox orgs by refreshing the sandbox org or by using the Match Production License tool. We explain more about updating sandbox orgs later. Provisioning does not apply to Demo, Developer, Scratch, or Trial orgs.

To understand licenses, let’s start with a little context. No doubt you’re familiar with Salesforce editions, such as Professional, Enterprise, and Unlimited. Editions bundle together features and services to address different levels of business needs. Maybe you also know about add-ons, which provide additional functionality to supplement an org’s edition. And you’ve probably heard of permissions and preferences (or perms and prefs), which control access to specific functionality for an org or for individual users.

So how do editions, add-ons, perms, and prefs fit together? The answer: licenses!

Perms and prefs are settings, or metadata switches that configure particular aspects of product functionality. In general, perms control access to features, such as Lightning Experience or Chatter, and certain aspects of security. Prefs define settings that customers can configure, such as time zone or password options. We explain more about perms and prefs in the next unit. For now, just keep in mind that perms and prefs are bundled into licenses that define functionality for the org as a whole (platform licenses) or for individual users (user licenses).

As an org admin, you assign each user one user license, based on the user’s role. The user license determines the functionality that the user can access. An edition or add-on can contain multiple types of user licenses, depending on the product. For example, the Sales Cloud Enterprise Edition includes the Full CRM user license for users who need access to CRM functionality, and also includes the Chatter Free license, for users who need access to Chatter but not to CRM features.

Many Salesforce products, such as Sales Cloud and Service Cloud, also include permission set licenses. Like user licenses, permission set licenses define user-level features. But while a user can have only one user license, the user can be assigned multiple permission set licenses. As an admin, you can assign permission set licenses to a user to augment the functionality provided by the assigned user license. After assigning user and permission set licenses, you take additional steps to determine the functionality that a given user has, by assigning profiles and permission sets. We explain more about that in the next unit.

Platform licenses, user licenses, and permission set licenses are all known as settings licenses, because they contain settings. In the next section, we see how settings licenses relate to editions and add-ons.

Note

Some Salesforce products do not provide user licenses or permission set licenses. For example, Heroku, the application development environment, creates platform licenses but no user licenses, because its products define functionality at the platform (org) level but not the user level.

OK, now we know a little about how licenses control platform- and user-level access in an org. But how does that relate to editions and add-ons?

As a Salesforce customer, you don’t directly buy individual perms or prefs. In fact, you don’t even buy individual platform, user, or permission set licenses (which are all settings licenses). Instead, you buy editions and add-ons, which are product licenses. Editions and add-ons bundle together platform, user, and permission set licenses in varying combinations to provide suites of functionality, so that you can easily select the package of features and services you need.

If we carry the lease agreement analogy a little further, we can think of platform, user, and permission set licenses like individual clauses in a lease, where each clause describes a specific property you are leasing (such as, “rooms 1 through 12 on floor 30, located at 125 Market Street”). The edition or add-on product license is like the lease document as a whole, which includes the clauses about specific properties, and general information about the manager-tenant agreement.

Each org has one edition, which provides all the functionality needed to activate the org. The edition is determined by the org's edition license, which is made up of a grouping of platform and user licenses. An org may have multiple contracts that grant users access to Salesforce via the org's one edition license. However, the org cannot grant users access to Salesforce via multiple edition licenses at the same time. An AddOn, as the name suggests, is an optional supplement that, like an edition, can contain platform and user licenses. While an org must have an edition, it can have any number of AddOns or no AddOns at all.

For an example of how editions and add-ons work together, let’s look at Ursa Major Solar, a Southwest-based supplier of solar components and systems. It’s a small company with around 200 employees.

Ursa Major purchases the Enterprise Edition of Service Cloud. As part of the edition, Ursa Major purchases 100 Full CRM user licenses, to give 100 employees access to Service Cloud CRM functionality.

Ursa Major also wants to use the customer service features provided by Salesforce Einstein, the comprehensive artificial intelligence system. Ursa Major purchases Service Cloud Einstein as an add-on. The add-on includes the Service Cloud Einstein permission set license, to assign to users who need access. At Ursa Major, only 10 account executives need the Einstein functionality, so Ursa Major purchases 10 Service Cloud Einstein permission set licenses as part of the add-on.

Add-on

An optional extension for an org to supplement the functionality provided by the edition. An org can have multiple add-ons. An add-on includes one or more permission set, platform, or user licenses, or a combination of those.

Demo org

A sample org used to demonstrate Salesforce functionality to prospective customers.

Developer org

A free, non-expiring org that a developer can use to develop, test, and deploy applications.

Edition

A bundle of features and services that comprise the functionality necessary to activate an org. Salesforce offers several editions, which provide varying levels of functionality.

License

The contractual agreement between Salesforce and a specific customer, which includes a metadata description of the functionality for the associated Salesforce product that is available to the customer org.

License definition

A metadata description of the functionality for a given Salesforce product that is available to a customer org.

Permission

A metadata switch, or setting, that configures a particular aspect of product functionality. In general, permissions control access to features, such as Lightning Experience or Chatter, and certain aspects of security. Compare to preference.

Permission set license

A license that defines user-level functionality, which can be assigned to supplement the functionality in a user license. A user can be assigned multiple permission set licenses. Note that a permission set license is different from a permission set, defined in the next unit.

Platform license

A license with metadata switches, or settings, that control functionality for the org as a whole.

Preference

A metadata switch, or setting, that configures a particular aspect of product functionality. In general, preferences define settings that customers can configure, such as time zone or password options. Compare to permission.

Product license

An edition or add-on, which bundles together one or more settings licenses and other metadata in a product that the customer can purchase.

Production org

Customer’s active org where users access and work with live data.

Provisioning

The process of activating licenses and enabling functionality in an org.

Sandbox org

A replica of a production org that serves as a staging environment where the customer can test changes without affecting the production org or users.

Scratch org

A short-lived deployment of Salesforce that enables developers to emulate different Salesforce editions, features, and preferences. Scratch orgs have a maximum 30 days lifespan.

Setting

A metadata switch in a license that configures a particular aspect of product functionality.

Settings license

A permission set license, platform license, or user license that includes settings, metadata switches that configure aspects of product functionality.

Trial org

A free org with sample data, designed for prospective customers to evaluate Salesforce before purchasing.

User license

A license that defines user-level functionality. Each user is assigned one user license.