Record Types & Page Layout Strategy 💬 In plain words: Record Types let one object act like different forms for different teams. Different picklist values, page layouts, and processes — same Account object. Use them for truly different business processes. Not for cosmetic layout changes. 📌 Example: One Account object, two businesses: 'Retail Customer' record type shows B2C picklist values and layout. 'Enterprise Client' shows contract fields and a different sales process. Same table, two costumes. 🧠One object, many costumes: A Record Type is a costume on the same object — different picklists and layouts, same table underneath. Concept Record Types split one object into business variants. • Each type can carry its own subset of picklist values, its own business process — Lead, Case and Opportunity stages — and its own page layout per profile. • Lightning has changed the calculus. Dynamic Forms and conditional comp...
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 ...