1.3 User & Feature Licensing
💬 In plain
words: The license is what the
company PAID for — it sets the ceiling of what a user could ever do. Profiles
and permission sets can only work below that ceiling. No license feature = no
amount of admin setup can grant it.
Concept
The User License (Salesforce, Salesforce Platform, Experience Cloud variants, etc.) sets the ceiling of what a user can ever be granted — profiles/permission sets can only work within it. Feature Licenses (Service Cloud User, Marketing User, Data Cloud) switch on product areas per user, and Permission Set Licenses (PSLs) entitle specific permissions (e.g., Einstein/Agentforce capabilities) that a permission set can then grant. Licensing is an architecture concern because it drives cost and constrains design: an object model that forces everyone onto full Salesforce licenses is an expensive design. Connects to 1.2 (grants must fit the license) and Module 19 (AI features are PSL-gated).
Core Q&A
Q: When do you put a user on
a Salesforce Platform license instead of a full Salesforce license, and what
breaks if you get it wrong?
🎯
Say this first: Platform license when the user only
touches custom apps — never standard Sales/Service objects; get it wrong and
their features simply don't exist.
A: Platform licenses suit
users who work only with custom objects plus a limited set of standard objects
(Accounts, Contacts, and a few others) — internal ops teams, approvers, report
consumers. They cannot use core CRM objects like Opportunities, Leads, or Cases
as first-class users, so if a 'platform' user type later needs pipeline access
you face a re-licensing bill or an anti-pattern (shadowing standard objects
with custom copies — a data-model smell). The architect's job is to map user
types to objects early and licence to the map; getting it wrong either
overspends (everyone on full CRM) or forces object-model distortions.
Follow-ups (scenario-based)
Q1: For an Experience Cloud
site with 40,000 rarely-active customers and 200 heavy-use partner firms, how
do you choose license models?
A1: Customers:
login-based Customer Community licenses — you pay per login pool, ideal for
large populations with sporadic access. Partners: member-based Partner
Community licenses for the heavy daily users (member-based wins when a user
logs in more than roughly a handful of times a month), and Partner (not
Customer) tier because they need sharing constructs like partner roles and
opportunity access. Show the interviewer you model expected login frequency
before picking, since the crossover point is a cost calculation, not a rule of
thumb.
Q2: An internal custom-object
application becomes a team's standard tool. How does licensing shape who can
use it?
A2: The platform's UI and
data model are custom objects plus Flow/LWC, so the consumer user type
(engineers logging tasks, leads reading delivery reports) fits Platform
licenses — only the user types touching CRM data need full licenses.
Agentforce/Einstein generative features are additionally gated by Permission
Set Licenses, so the AI capabilities were exposed through a dedicated
permission set backed by the PSL, assigned only to user types that genuinely
invoke generation. That framing — custom-object product, platform-licensed
consumers, PSL-gated AI — demonstrates cost-aware architecture, which is
precisely what an architect round probes for.