Master-Detail vs Lookup 💬 In plain words: Master-Detail is a parent-child bond: child dies with the parent, inherits its sharing, and enables roll-up summaries. Lookup is a loose reference: both records live independently. Choose MD when the child has no meaning alone; choose lookup when it does. 📌 Example: Invoice Line without an Invoice is meaningless → Master-Detail: delete the invoice, lines go too, and 'Invoice Total' is a free roll-up. Contact to 'Preferred Hotel' → Lookup: hotel deleted, contact lives on. 🎬 Real-Life Example: The Roll-Up That Cost a Sprint Every Route__c screen must show how many Delivery__c records it carries. Simple total. Live at all times. The Old/Bad Way: The team built Route–Delivery as a Lookup. Lookups have no roll-up summary fields. So they wrote a trigger: count children on insert, subtract on delete, recount on reparent, handle undelete, handle bulk loads. Why this is bad: You are rebuilding...
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...