Salesforce Basics: 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 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)