Add-on
An Add-on in Salesforce is a licensed product that extends the functionality of a base edition (Sales Cloud, Service Cloud, Experience Cloud, Marketing Cloud, and so on) without requiring an edition upgrade.
Definition
An Add-on in Salesforce is a licensed product that extends the functionality of a base edition (Sales Cloud, Service Cloud, Experience Cloud, Marketing Cloud, and so on) without requiring an edition upgrade. Add-ons are sold separately at a per-user-per-month price and turn on additional features, objects, permission set licences, and APIs that the base edition does not include. Common examples include Sales Cloud Einstein, Sales Engagement, Inbox, Service Cloud Voice, Salesforce CPQ, Salesforce Maps, and Field Service. Add-ons are how Salesforce monetises advanced capability without forcing every customer to upgrade their whole edition tier.
Add-ons differ from AppExchange managed packages in one important way: they are Salesforce-built first-party products that integrate natively with the core platform's UI, permissions, and data model. They show up in Setup as if they were part of the platform, ship with their own Permission Set Licences (PSLs), and often add tabs, objects, and entire Lightning apps. Customers usually activate an add-on through a provisioning step at the contract level, after which an admin assigns the new PSL and permission sets to the users who need the feature.
How Add-ons fit into the Salesforce licensing model
Add-ons versus full edition upgrades
An edition upgrade (say Sales Cloud Professional to Enterprise) changes the foundational capability of the whole org for every user. An add-on layers a specific capability on top, often for a subset of users. A 200-seat org might have 20 users on Sales Cloud Einstein add-on while the rest stay on plain Enterprise. The pricing reflects the scope: edition upgrades cost more per seat but cover more capabilities, while add-ons are narrower but can be deployed selectively.
Permission Set Licences and the activation path
Most add-ons land in the org as Permission Set Licences (PSLs). The PSL is a count of how many users can have the feature, separate from the regular user licence. Admins assign the PSL to individual users, then assign one or more permission sets that grant the actual permissions. This two-step model is intentional: it lets admins audit who has the add-on, separate from who has any other access.
The most common Sales Cloud add-ons
Sales Cloud add-ons include Sales Cloud Einstein (lead scoring, opportunity scoring, activity capture insights), Sales Engagement (high-velocity sales cadences and work queues), Inbox (Gmail and Outlook integration with email tracking and templates), and Salesforce CPQ (quoting, pricing, contracting). Each is licensed per user. Some, like Inbox, are bundled into higher editions; the same product can be a standalone add-on for one tier and bundled for another.
The most common Service Cloud add-ons
Service Cloud add-ons include Service Cloud Voice (native telephony with Amazon Connect or a partner), Field Service (mobile work orders and dispatch), Digital Engagement (messaging channels: SMS, WhatsApp, Facebook Messenger), and Service Cloud Einstein (case classification, recommended replies, article recommendations). Like Sales Cloud add-ons, each requires a PSL count and permission set assignment.
Marketing, Data Cloud, and platform add-ons
Marketing Cloud Engagement, Marketing Cloud Account Engagement (Pardot), Marketing Cloud Personalization, Marketing Cloud Intelligence, and Data Cloud are sometimes considered add-ons relative to the core CRM, though they are increasingly sold as standalone products. Platform add-ons include Shield (encryption, event monitoring), Privacy Center (data subject rights), and Salesforce Backup. Each behaves differently in Setup; some appear as separate apps, others as toggles inside Setup pages.
First-party add-ons versus AppExchange managed packages
AppExchange packages are partner-built. They install as managed packages, may carry their own licensing through the partner's price book, and live in their own namespace. Add-ons are first-party Salesforce products with no namespace prefix and tighter integration with core objects. The difference matters during incidents: when a first-party add-on breaks, Salesforce Support owns the fix. When a managed package breaks, support routes through the ISV.
Licence counting and over-deployment risk
The PSL count caps how many users can have the add-on at a time. Trying to assign one more PSL than the contract allows produces an error. Some legacy add-ons used to allow over-assignment with a true-up at renewal; modern PSLs enforce the count up front. Admins should run regular PSL utilisation reports so renewals reflect what users are actually using, not what was provisioned years ago.
Adopting an add-on, the implementation lifecycle
A clean add-on rollout looks like: contract execution, provisioning by Salesforce, PSL appears in Setup, admin assigns to a pilot group, pilot validates the feature against real workflows, admin creates the permission sets that fit the org's role model, broader rollout to the rest of the licensed users, then a 90-day adoption check. Skipping the pilot phase is the most common cause of failed add-on rollouts; the feature works on paper but does not match how the team really works.
How to roll out a Salesforce Add-on
Rolling out an add-on takes contract action, provisioning, and the standard permission-assignment loop. The mechanics are similar across add-ons; the differences are in which permission sets and PSLs the specific product uses.
- Confirm contract and provisioning
The add-on must be on the contract and provisioned by Salesforce. Check the Permission Set Licences page in Setup. If the PSL is not listed with a non-zero count, contact the AE or partner CSM before going further.
- Assign the Permission Set Licence
Setup, Permission Set Licences, click the PSL, then Manage Assignments. Assign it to the pilot users first. PSL assignment is the gate; permission sets without the PSL will not grant the add-on permissions.
- Create or clone a permission set
Most add-ons ship with one or more default permission sets. Clone the one closest to your needs, name it for your org's convention, and adjust object and field permissions to match your role model.
- Pilot with a small user group
Assign the permission set to five to ten users. Watch how they use the add-on for two to four weeks. Adjust setup, automation, and training material based on what you learn.
- Roll out broadly and track utilisation
Once the pilot validates the design, assign the permission set to the wider audience. Build a usage dashboard (logins, feature interactions, key actions) to prove value and to inform the next renewal conversation.
- Permission Set Licence assignment is required before the permission set takes effect. Assigning the permission set first without the PSL gives users an error.
- Over-assigning PSLs is now blocked at the platform level. Reorder more seats before rolling out beyond the contracted count.
- Some add-ons require a sandbox refresh after provisioning to make the feature visible in sandboxes. Plan dev work accordingly.
- Add-on availability varies by edition. A few add-ons require Enterprise or Unlimited even after purchase. Confirm prerequisites before signing.
Trust & references
Cross-checked against the following references.
- Permission Set LicencesSalesforce Help
- Sales Cloud Editions and PricingSalesforce
Straight from the source - Salesforce's reference material on Add-on.
- Understanding License TypesSalesforce Help
Hands-on resources to go deeper on Add-on.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What architecture concept is Add-on an example of?
Q2. What does Add-on represent in the Salesforce Platform?
Q3. How does Salesforce's multi-tenant model affect Add-on?
Discussion
Loading discussion…