Interview Questions

Salesforce uses a layered security model with 4 levels: Organisation Level: Org-wide settings, trusted IPs, login hours, password policies, session settings. Object Level (OLS): Controlled via Profile and Permission Sets — CRUD access on objects. Field Level Security (FLS): Controls visibility and editability of individual fields via Profile/Permission Sets. Record Level: Determined by OWD → Role Hierarchy → Sharing Rules → Manual Sharing → Apex Sharing. Record level is always additive — you can only open access, never restrict below OWD once open (except via restriction rules in newer releases).

OWD sets the baseline record access for all users. Options: Private, Public Read Only, Public Read/Write, Controlled by Parent (for detail objects in MD). For external users: Private, Public Read Only. Default access for a new custom object is Private if not configured.

Roles define a tree structure. Users higher in the hierarchy automatically gain read/edit access to records owned by users below them — if 'Grant Access Using Hierarchies' is enabled on the object. Roles do NOT restrict access; they only open it upward. Note: Roles are not mandatory for every user.

Sharing Rules automatically extend record access beyond OWD to specific groups/roles/users. Two types: (1) Criteria-based — shares records matching field criteria; (2) Owner-based — shares records owned by a role/group. Access levels available: Read Only or Read/Write.

Possible reasons: (1) Manual sharing — someone shared extra records with the 100-record user; (2) Apex sharing — programmatic sharing added; (3) The user with 100 records is higher in role hierarchy or has a different role; (4) Different teams in territory management; (5) The user has 'View All' on some record type; (6) Sharing sets in Experience Cloud. OWD alone cannot explain this if profile/role are identical.

Options: (1) Role Hierarchy — put User B above User A; (2) Sharing Rule — criteria or owner-based; (3) Manual Sharing — owner clicks Share button; (4) Apex Sharing — insert into Account/Object share table; (5) Public Group — add user to a group covered by a sharing rule.

Apex Sharing programmatically creates entries in the Share object (e.g., AccountShare, Case_Share__c for custom objects). Used when sharing logic is too complex for sharing rules. AccountShare share = new AccountShare(); share.AccountId = accountId; share.UserOrGroupId = userId; share.AccountAccessLevel = 'Edit'; share.OpportunityAccessLevel = 'Read'; share.RowCause = Schema.AccountShare.RowCause.Manual; insert share; For custom objects, the RowCause should be a custom share reason defined in the object settings. Apex sharing entries persist even if sharing rules change, unlike criteria-based shares which recalculate.

with sharing: Enforces sharing rules — user only sees records they have access to (record-level). Does NOT enforce OLS or FLS automatically. without sharing: Runs in system context — all records visible regardless of user's sharing settings. Useful for background/admin operations. inherited sharing: Class inherits the sharing context of its caller. If called from a 'with sharing' class, it runs with sharing. If called from 'without sharing', it runs without. Default for classes without declaration is also inherited (effectively without sharing when called directly). Key scenario: A 'without sharing' class called from a 'with sharing' class — the without sharing class ignores the caller's sharing context and runs in system mode.

No. 'with sharing' only enforces record-level sharing rules. To enforce OLS, use Schema.sObjectType.Account.isAccessible(). To enforce FLS, use Schema.sObjectType.Account.fields.Name.isAccessible(). Or use WITH SECURITY_ENFORCED in SOQL, or use Security.stripInaccessible() for both read and write operations.

Profiles can set: Login Hours, Login IP Ranges, Page Layout Assignments, Record Type Defaults, App visibility (default app). Permission Sets cannot configure these — they can only add/grant permissions, never restrict. In Salesforce's roadmap, profiles will eventually be replaced by permission sets + permission set groups.

Permission Set: A collection of permissions assigned to individual users in addition to their profile. Permission Set Group: A bundle of multiple permission sets, assigned as a single unit to users. Muting Permission Sets can be included in a group to suppress specific permissions within that group.

You cannot remove/restrict access through permission sets — they only grant. Solutions: (1) Create a new profile with Read-only and assign to those 2 users; (2) Use a Restriction Rule (available from Summer '21) to limit record access further; (3) For field-level restriction — use field-level security on a new profile. Note: From Winter '23, you can enable 'User Permissions' on permission sets to potentially solve some restrictions.

Manual sharing lets the record owner (or admin) share an individual record with a user/group/role. The Share button is not visible when: (1) OWD is Public Read/Write (no need to share); (2) The user doesn't own the record and doesn't have 'Modify All' permission; (3) 'Manual User Record Sharing' is disabled in org settings.

Restriction Rules (introduced Summer '21) allow you to restrict which records a user can see — filtering records from the user's view even if OWD allows access. Unlike sharing rules which open access, restriction rules narrow it. They use filter criteria and can be applied per user criteria (profile, permission set, etc.).