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).
1.2 Profiles vs Permission Sets vs Permission Set Groups 💬 In plain words: A Profile is the base uniform every user wears — everyone has exactly one. Permission Sets are extra badges you pin on top for special access. Permission Set Groups are a ready-made bundle of badges. Modern rule: keep the profile minimal, give everything through badges. Concept A Profile is the mandatory 1-per-user baseline (login hours, IP ranges, page-layout assignment, default record types); Permission Sets are additive grants stacked on top; Permission Set Groups (PSGs) bundle permission sets into a user type, with Muting Permission Sets to subtract specific permissions from the bundle without editing its members. Salesforce's stated direction is the 'Minimum Access' profile plus user type-based PSGs — profiles are being progressively drained of permissions (EOL of permissions on profiles has been repeatedly signposted). This underpins Object/Field security (1.4) and interacts with ...