Mastering Salesforce: Step by Step

  Junction Objects & Schema Limits 💬 In plain words:  A junction object is a small 'middle table' with two master-details, used when both sides can have many of each other (Students ↔ Courses → Enrollment). It's how you build many-to-many on the platform. 📌 Example:  Students and Courses: one student takes many courses, one course has many students. Create Enrollment with two Master-Details — the junction. Ravi's enrollment in 'Apex 101' is one Enrollment record carrying grade and enrollment date. 🧠 The middle table:  Many-to-many = two master-details meeting in a small middle object. Students and Courses meet in Enrollment; Skyline's Parcels and Routes meet in a Stop. 🔗 Connects to:   the master-detail choice both legs depend on   ·    one busy parent record creates data skew at scale Concept A junction object models many-to-many. It is a custom object with two Master-Detail relationships. •...

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...

  Reports, Dashboards & Analytics Architecture 💬 In plain words:  Reports are questions you ask of your data; report types decide which objects a report is even allowed to ask about; dashboards show many answers on one screen. Key trap: who a dashboard 'runs as' decides whose data everyone sees. 📌 Example:  The VP's dashboard shows 40 deals; a rep opens the same dashboard and sees 12. Check 'view dashboard as': it runs as the viewer, and the rep's sharing only reaches 12 opportunities. Same report, different eyes. Concept Reporting starts with Report Types. A report type decides which objects and fields are reportable, and whether the join is inner or outer, that is the 'with or without related records' choice. It is the most under-appreciated lever on the platform. Custom report types unlock cross-object paths and relationships that are otherwise hidden. Reporting snapshots capture data at a point in time into a custom object, whic...

 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).