Schema.DescribeFieldResult dfr = Account.CreditCardNumber__c.getDescribe(); if (dfr.isAccessible()) { // safe to read }

HttpRequest req = new HttpRequest(); req.setEndpoint('callout:OrgB_Credential/services/data/v59.0/sobjects/Account/'); req.setMethod('POST'); req.setHeader('Content-Type', 'application/json'); req.setBody('{"Name":"Acme Corp"}'); Http http = new Http(); HttpResponse res = http.send(req);

VP Sales └── Regional Manager (East) └── Sales Rep A └── Sales Rep B └── Regional Manager (West) └── Sales Rep C └── Sales Rep D

Security Evaluation Order: OWD → Role Hierarchy → Sharing Rules → Manual → Apex

Setup → Sharing Settings → [Object] → Default Internal Access = Private

User A (Manager Role) ← sees more records └── User B (Rep Role) ← sees fewer records A is ABOVE B → A sees B's records ✅ B is BELOW A → B cannot see A's records ❌ Hierarchy is UPWARD ONLY

CEO └── BU A Head → BU A Manager → BU A Reps └── BU B Head → BU B Manager → BU B Reps └── BU C Head → BU C Manager → BU C Reps

List<UserRecordAccess> access = [ SELECT RecordId, HasReadAccess, HasEditAccess FROM UserRecordAccess WHERE UserId = :userAId AND RecordId = :recordId ];

Permission Set: Finance_Field_Access → Custom Field A: Visible + Editable → Custom Field B: Visible + Read Only Permission Set: HR_Field_Access → Custom Field C: Visible + Editable → Custom Field A: Hidden Permission Set: Sales_Field_Access → Custom Field B: Visible + Read Only

// Step 1 — OWD to Private Setup → Sharing Settings → Feedback__c → Default Internal Access = Private // Step 2 — KEY STEP: Uncheck Grant Access Using Hierarchies Setup → Sharing Settings → Feedback__c → Uncheck "Grant Access Using Hierarchies"

trigger FeedbackSharingTrigger on Feedback__c (after insert) { User ceo = [SELECT Id FROM User WHERE UserRole.Name = 'CEO' LIMIT 1]; List<Feedback__Share> shares = new List<Feedback__Share>(); for (Feedback__c fb : Trigger.new) { Feedback__Share s = new Feedback__Share(); s.ParentId = fb.Id; s.UserOrGroupId = ceo.Id; s.AccessLevel = 'Read'; s.RowCause = Schema.Feedback__Share.RowCause.Manual; shares.add(s); } insert shares; }

Security Evaluation Order: Profile (CRUD) → FLS → OWD → Role Hierarchy → Sharing Rules → Ownership Profile is evaluated FIRST — if it says Read Only, edit is blocked at the very first gate ❌

Contact (Parent) OWD = Public Read Only ↓ (Master-Detail) College (Child) OWD = Controlled by Parent ↓ College = Public Read Only automatically ❌ Cannot give Read/Write via OWD!

Contact (Parent) OWD = Public Read Only ↓ (Lookup — loose coupling) College (Child) OWD = Public Read/Write ✅ ↓ College = Read/Write independently!

Profile gives READ access ↓ Opens the DOOR to Contact object ↓ OWD = Private controls WHICH records inside ↓ A can only see A's records ✅ B can only see B's records ✅ Neither can see each other's records ✅ — by design!

// Step 1 — Create Two Record Types Setup → Object Manager → Contact → Record Types → New → Record Type 1: Type_A → Record Type 2: Type_B // Step 2 — Create Two Page Layouts Setup → Object Manager → Contact → Page Layouts → New → Layout_For_User_A → Layout_For_User_B // Step 3 — Map Record Type → Page Layout Setup → Object Manager → Contact → Page Layout Assignment Profile | Record Type | Page Layout Sales Profile | Type_A | Layout_For_User_A Sales Profile | Type_B | Layout_For_User_B

OWD → Role Hierarchy → Sharing Rules → Manual Sharing Record Type assignment has ZERO impact on this chain!

Person 1 → Record Owner Person 2 → Role Hierarchy (Manager of Person 1) Person 3 → Owner-Based Sharing Rule Person 4 → Manual Sharing Person 5 → Apex Managed Sharing

// Custom RowCause = SURVIVES ownership change ✅ share.RowCause = Schema.AccountShare.RowCause.MyCustomReason__c; // Manual RowCause = DELETED on ownership change ❌ share.RowCause = Schema.AccountShare.RowCause.Manual;

Step 1 — Freeze old user (don't delete immediately) Step 2 — Mass Transfer all records to new rep Step 3 — Deactivate old user Step 4 — Assign new rep correct Role + Profile ⚠️ NEVER delete a user in Salesforce — always deactivate!

// Case 1 — Without FLS Check (Default — UNSAFE ⚠️) public without sharing class FetchData { public static void run() { List<Account> accs = [ SELECT Id, Name, CreditScore__c FROM Account ]; // ✅ ALL records returned // ✅ ALL fields returned including restricted ones ⚠️ } } // Case 2 — WITH SECURITY_ENFORCED List<Account> accs = [ SELECT Id, Name, CreditScore__c FROM Account WITH SECURITY_ENFORCED // ← Enforces FLS ]; // ❌ Throws QueryException if user lacks FLS on any field // Case 3 — Security.stripInaccessible (Best Practice ✅) List<Account> accs = [SELECT Id, Name, CreditScore__c FROM Account]; SObjectAccessDecision d = Security.stripInaccessible( AccessType.READABLE, accs ); List<Account> safe = d.getRecords(); // ✅ Records returned, restricted fields automatically STRIPPED

// Golden Rule: with/without sharing = Record Level (WHO sees WHICH records) FLS = Field Level (WHO sees WHICH fields) with sharing does NOT automatically enforce FLS! FLS must be enforced SEPARATELY in Apex code! // Key Difference: without sharing → ALL records returned (ignores sharing) ALL restricted fields returned (ignores FLS) with sharing → ONLY accessible records returned (respects sharing) ALL restricted fields STILL returned (FLS still ignored!) FLS behaviour is IDENTICAL in both unless explicitly enforced!

// How to Use in Apex AccountShare share = new AccountShare(); share.AccountId = recordId; share.UserOrGroupId = userId; share.AccountAccessLevel = 'Read'; share.RowCause = Schema.AccountShare.RowCause.MyCustomReason__c; // ← Sharing Reason insert share; // How to Delete Shares by RowCause List<AccountShare> toDelete = [ SELECT Id FROM AccountShare WHERE RowCause = 'Territory_Based_Sharing__c' AND AccountId = :recordId ]; delete toDelete;

Ownership Changes ↓ Manual Share (RowCause = Manual) → ❌ DELETED automatically Apex Share (RowCause = Custom__c) → ✅ SURVIVES — stays intact

Admin deletes Apex Sharing Reason from Setup ↓ Salesforce finds ALL AccountShare records where RowCause = deleted sharing reason ↓ ALL those share records deleted instantly ↓ ALL users lose access to those records ❌

// Step 1 — Delete share records via Apex FIRST List<AccountShare> toDelete = [ SELECT Id FROM AccountShare WHERE RowCause = 'Territory_Access__c' ]; delete toDelete; // Step 2 — Then delete Sharing Reason from Setup safely

// Step 1 — OWD to Private Setup → Sharing Settings → Account → Default Internal Access = Private // Step 2 — Role Hierarchy Senior Manager └── Manager └── Team Lead └── Team Member

TWO layers must BOTH allow it: Layer 1 — Profile CRUD → Does user have DELETE permission? Layer 2 — Record Access → Does user have access to THAT record? BOTH must be YES to delete ✅