Object -Level & Field-Level Security (CRUD/FLS) 💬 In plain words: Two locks on data: object-level (can you touch Accounts at all — Create/Read/Update/Delete) and field-level (okay, but can you see the Salary field?). Sharing decides WHICH records; CRUD/FLS decides WHAT you can do with the object and its fields. 📌 Example: Asha can see the Candidate object (object-level ✓) but the Salary field is hidden from her profile (field-level ✗). She opens the record fine — the Salary column is simply not there, even in reports and the API. Concept CRUD (object permissions) and FLS (field permissions) are granted via profiles/permission sets and are enforced automatically in the standard UI, standard controllers, and Lightning Data Service — but NOT automatically in Apex, which runs in system mode by default on API v66 and earlier (from v67, user mode is the default — see 3.7). In older code Apex must opt in: SOQL with WITH USER_MODE, DML with 'as user', or ...
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).