Record-Level Security
Record-Level Security in Salesforce is the layer of the security model that determines which individual records a user can see, edit, or own once the user already has object access.
Definition
Record-Level Security in Salesforce is the layer of the security model that determines which individual records a user can see, edit, or own once the user already has object access. Where object permissions answer "can this user read Opportunities at all," record-level security answers "which Opportunities can this user read." It is the second control after object-level access and the most flexible because it operates on a per-record basis through ownership, role hierarchy, sharing rules, manual sharing, teams, and other granular mechanisms.
Record-Level Security is what makes Salesforce work as a multi-tenant CRM where many users with the same object permissions still see different records. A sales rep in EMEA sees their EMEA opportunities; a rep in NA sees their NA opportunities; both have identical Read access on Opportunity at the object layer, but record-level security keeps their working sets separate. The administrator configures this through Org-Wide Defaults, Role Hierarchy, Sharing Rules, Manual Sharing, Account/Opportunity Teams, Territory Management, Apex Sharing, and Implicit Sharing, layered together to express the desired access pattern.
The seven mechanisms that compose record-level security in Salesforce
Org-Wide Defaults (OWD)
The starting point for record-level security is the Org-Wide Default per object. OWD has four values: Private (only owner and admin see), Public Read Only (everyone reads, only owner edits), Public Read/Write (everyone reads and edits), Controlled by Parent (inherits from a master record). Salesforce recommends starting Private for sensitive objects and opening access deliberately through other mechanisms rather than starting Public and trying to lock down later. OWD sets the baseline; every other mechanism opens access selectively from there.
Role Hierarchy
The Role Hierarchy automatically grants users access to records owned by users below them. A VP of Sales sees every Opportunity owned by every rep on their team because their role is higher in the hierarchy. The Grant Access Using Hierarchies flag on each object controls whether hierarchy-based sharing applies; the default is on for standard objects and configurable for custom. The hierarchy is one of the cheapest ways to express manager-rolls-up-rep visibility and is the default mechanism most orgs lean on.
Sharing Rules
Sharing Rules grant access based on record criteria or owner. Criteria-based sharing rules ("share every Opportunity with Region = EMEA to the EMEA Reps public group") open access automatically when records match. Owner-based sharing rules ("share every Account owned by a member of Public Group X with Public Group Y") open access by ownership. Both run asynchronously when records change, with the recalculation queue handling large updates over time. Sharing rules are the bulk-grant mechanism that complements OWD-Private starting points.
Manual Sharing
Manual Sharing lets record owners share an individual record with a specific user, role, public group, or queue, with read or read/write access. The Sharing button on the record detail page opens the manual share dialog. Manual shares are persistent until explicitly revoked or until the record changes owner, in which case they typically clear. The mechanism is the user-driven layer for one-off cases where automation does not cover the need.
Account, Opportunity, and Case Teams
Salesforce includes team mechanisms on Account, Opportunity, and Case. An Account Team grants additional users access to an Account and (configurably) its children. An Opportunity Team grants additional users access to a specific deal. Each team member has a configurable access level (Read, Read/Write, Owner) and an optional role tag (Sales Engineer, Solution Architect). Teams are the user-driven mechanism for collaborative deals where the owner is not the only person who needs access.
Territory Management
Enterprise Territory Management is a specialized record-level security feature for sales organizations with geographic or segment-based territory structures. Records are assigned to Territories (regions, segments, named accounts), users are assigned to Territories with access levels, and the platform shares records based on territory membership. This is more expressive than role hierarchy alone because a user can belong to multiple territories simultaneously, which models real-world sales coverage better than a strict tree.
Apex Sharing and Implicit Sharing
Two specialized mechanisms close the gaps. Apex Sharing lets developers programmatically insert ObjectShare records (AccountShare, OpportunityShare) for cases the declarative tools cannot express ("share every Opportunity to the rep who created the original Lead"). Implicit Sharing is platform-managed: a user with Account access automatically gets implied access to certain children (Contacts, Cases, Opportunities) per documented rules. Both run alongside the declarative mechanisms; neither replaces the foundational OWD baseline.
Design record-level security for a new Salesforce object
Start with the most restrictive baseline, then layer the sharing mechanisms that grant exactly the access each user role needs.
- Set the Org-Wide Default
Setup, Sharing Settings. Set the new object's OWD to Private. This locks the records to the owner only by default.
- Confirm role hierarchy use
On the same screen, confirm Grant Access Using Hierarchies is checked. Managers will automatically see records owned by reps below them in the role tree.
- Create sharing rules for cross-team access
Sharing Rules section. Create a criteria-based rule that shares records with a public group based on a field value (Region equals EMEA shares to EMEA Reps).
- Add team functionality if needed
For objects with collaborative deal cycles, enable Account Teams or Opportunity Teams. Train users to add team members when they need additional collaborators.
- Document Apex Sharing requirements
For cases declarative tools cannot express, document the requirement and have a developer implement an Apex Sharing trigger. Test thoroughly in a sandbox.
- Audit before go-live
Run the Sharing Settings audit. As a non-admin test user, verify you see exactly the records expected and nothing more.
Baseline: Private, Public Read, Public Read/Write, Controlled by Parent.
Automatic upward access grant based on the user role tree.
Bulk-grant mechanism based on criteria or ownership.
User-driven one-off share on an individual record.
Per-record collaborator lists on Account, Opportunity, Case.
Multi-membership geographic or segment-based sharing.
Programmatic ObjectShare records for cases declarative tools cannot express.
- Public Read/Write at the OWD level overrides every other share mechanism. Once an object is public, sharing rules and teams add nothing; revert to Private first if you need fine-grained control.
- View All Data and Modify All Data system permissions bypass record-level security entirely. Users holding them see everything regardless of OWD and sharing rules.
- Sharing rule recalculation can take hours on large orgs. Bulk owner changes or sharing rule edits should be scheduled outside business hours.
- Apex Sharing requires the object's OWD to be Private or Public Read. Public Read/Write does not need it and rejects it; if you wrote an Apex sharing trigger and then changed OWD to Public, the trigger fails.
Trust & references
Cross-checked against the following references.
- Salesforce Data AccessSalesforce Help
- Org-Wide DefaultsSalesforce Help
- Salesforce Security Implementation GuideSalesforce Developer Docs
Straight from the source - Salesforce's reference material on Record-Level Security.
- Record-Level Security DocumentationSalesforce Help
- Sharing RulesSalesforce Help
- Apex SharingSalesforce Developer Docs
Hands-on resources to go deeper on Record-Level Security.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Record-Level Security?
Q2. How is it enforced?
Q3. What are the three security layers?
Discussion
Loading discussion…