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...
1.6 Custom Permissions 💬 In plain words: A Custom Permission is a simple yes/no flag you attach to users, which your code and flows can check — like a feature switch per person. Use it instead of hardcoding profile names in logic. 📌 Example: Validation rule blocks editing closed Cases — but the audit team must edit them. Create Custom Permission 'Edit_Closed_Cases', add NOT($Permission.Edit_Closed_Cases) to the rule, assign it to auditors via a permission set. No profile checks in formulas. 🎬 Real-Life Example: Bypassing a Validation Rule Imagine you have a rule: no one can discount an Opportunity by more than 20%. But the VP of Sales needs to override this rule when closing major deals. The Old/Bad Way (hardcoding): You write a validation rule that checks the user's profile name: Discount__c > 0.20 && $Profile.Name != 'System Administrator' && $Profile.Name != 'VP of Sales'. Why this is bad: If you...