Custom Metadata Types vs Custom Settings vs Custom Labels 💬 In plain words: Three lookalikes: Custom Metadata = configuration that DEPLOYS with your code (best for app settings). Custom Settings = org/user-specific values, changeable at runtime (hierarchy type is great for bypass switches). Custom Labels = translatable text for the UI. 📌 Example: API endpoint URLs per environment → Custom Metadata (deploys with code, sandbox vs prod values). A 'Bypass_Automation__c' checkbox an admin flips during data load → hierarchy Custom Setting. The word 'Submit' translated to Hindi → Custom Label. 🎬 Real-Life Example: The Fee Table Trapped Inside Code Skyline charges a different delivery fee per city. Apex needs those rates on every booking. The Old/Bad Way: if (city == 'Delhi') fee = 50. Else if (city == 'Mumbai') fee = 65. … Every rate change is a code change, a test run, and a deployment. Why this is bad: Business data is trappe...
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).