๐ฌ 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 absolute ceiling of what a user can ever be granted — profiles and permission sets can only work within those boundaries.
- Feature Licenses: (e.g., Service Cloud User, Marketing User, Data Cloud) switch on specific product areas per user.
- Permission Set Licenses (PSLs): Entitle specific platform capabilities (e.g., Einstein and Agentforce capabilities) that a Permission Set can then assign.
- Architectural Impact: Licensing drives total cost of ownership and constrains schema design. An object model that unnecessarily forces every user onto full Salesforce CRM licenses is an expensive design anti-pattern.
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 strictly with custom objects plus a limited set of core standard objects (Accounts, Contacts, and custom tabs) — internal operations teams, approvers, or internal reporting consumers.
- Platform users CANNOT access core CRM objects like Opportunities, Leads, or Cases as first-class users.
- If a Platform user later requires pipeline or Case access, you face a major re-licensing cost or an architectural anti-pattern (shadowing standard CRM objects with custom copies).
- Architect Responsibility: Map user personas to objects early in the discovery phase and align licensing directly to that matrix to prevent cost overruns or schema 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: Align the license model with expected user volume and interaction frequency:
- Customers (40,000): Use login-based Customer Community licenses. You purchase a shared monthly login pool, making it cost-effective for large populations with sporadic access.
- Partners (200): Use member-based Partner Community licenses. Member-based pricing is cheaper when users log in frequently (typically more than 4–5 times a month).
- Tier Selection: Partners require the Partner Community tier (rather than Customer Community) to grant access to advanced sharing constructs like Partner Roles, Role Hierarchy inheritance, and Opportunity sharing.
Q2: An internal custom-object application becomes a team's standard tool. How does licensing shape who can use it?
A2: Design the access tier around the underlying data requirements:
- Custom Workflows: Internal users who only interact with custom objects, Flows, and LWCs (e.g., field engineers logging tasks) need only Salesforce Platform licenses.
- Core CRM Access: Reserve full Salesforce CRM licenses exclusively for personas interacting with Sales and Service objects.
- AI Capabilities: Generative AI and Agentforce capabilities are entitlement-gated via Permission Set Licenses (PSLs). Assign the PSL and its backing Permission Set specifically to the personas invoking those generative features to optimize licensing costs.
Recommended Reading: Object-Level & Field-Level Security (CRUD/FLS)