Imagine this: a sales rep logs into Salesforce and accidentally sees a confidential deal that belongs to a different regional team. Or worse — a new hire can edit sensitive contract records they should never touch. This is not just an awkward situation; it is a serious Data security risk.
This is exactly the problem that Record Level Security in Salesforce is designed to solve. As one of the most critical pillars of the Salesforce data security model, record-level security gives administrators granular control over which users can view, edit, or share individual records — without affecting access to the broader object or field.
In this comprehensive guide, we will walk you through everything you need to know about Record Level Security in Salesforce — what it is, why it matters, the four key mechanisms to implement it, and practical tips to master it as a Salesforce Admin.
Record Level Security in Salesforce is a system that controls which individual records a user can view, edit, delete, or share within an object. While object-level permissions answer the question “Can this user access Accounts?”, and field-level security answers “Can this user see the Annual Revenue field?”, record-level security goes one layer deeper — it answers the specific question: Which Account records can this user see?
In Salesforce’s layered security architecture, permissions are always evaluated by combining object, field, and record-level settings. The key rule is: when object-level and record-level permissions conflict, the most restrictive setting wins.
Key Principle: Object-level security is a prerequisite. If a user has no object access, record-level security cannot grant them access to individual records within that object. But if object access exists, record-level security determines exactly which records they can interact with.
Why Record Level Security Matters
Implementing Record Level Security in Salesforce is not optional for any serious organization. Here is why it is essential:
Implementing Record Level Security in Salesforce is not optional for any serious organization. Here is why it is essential:
- Data Confidentiality: Prevents unauthorized users from viewing sensitive records like high-value deals, legal cases, or payroll data.
- Regulatory Compliance: Helps meet industry regulations such as GDPR, HIPAA, and SOC 2 by restricting data access to only those who need it.
- Reduced Data Breach Risk: Limits the blast radius of potential insider threats or compromised accounts.
- Improved User Experience: When users only see records relevant to their role, there is less clutter and confusion.
- Data Integrity: Ensures users can only modify records relevant to their work, reducing the risk of accidental or unauthorized changes.
- Scalable Collaboration: Enables teams across departments to securely share records when genuinely needed.
How the Salesforce Security Model Layers Work
Before diving into record-level security specifics, it helps to understand where it fits in Salesforce’s broader security model. Salesforce uses a layered approach — each layer builds upon the previous one:
| Security Layer | What It Controls | Tool Used |
|---|---|---|
| Organization Level | Who can log in and from where | Profiles, Login Hours, IP Restrictions |
| Object Level | Which objects a user can access | Profiles, Permission Sets |
| Field Level | Which fields within an object are visible | Field-Level Security (FLS) |
| Record Level | Which specific records a user can access | OWD, Role Hierarchy, Sharing Rules, Manual Sharing |
Record Level Security is the most granular layer. It operates within the boundaries set by the layers above it and uses four distinct mechanisms, which we will explore in detail below.
The Four Pillars of Record Level Security in Salesforce
Salesforce provides four primary strategies for implementing record-level security. Think of them as a layered toolkit — you typically start with the most restrictive baseline and progressively open access where your business requires it.
![Record Level Security in Salesforce – Four Pillars: OWD, Role Hierarchy, Sharing Rules, Manual Sharing]
Organization-Wide Defaults (OWD)
Organization-Wide Defaults set the baseline access level for every record in every object across your entire Salesforce org. OWD is the foundation upon which all other record-level security mechanisms are built.
OWD access options include:
- Private: Only the record owner and users above them in the role hierarchy can access the record.
- Public Read Only: All users can view records, but only the owner (and those above in the hierarchy) can edit them.
- Public Read/Write: All users can view and edit any record.
- Public Read/Write/Transfer: Users can view, edit, and transfer ownership (available for objects like Cases and Leads).
Admin Best Practice: Always start by setting OWD to Private for sensitive objects, then use the other three mechanisms to open access where needed. It is far easier to grant additional access than to restrict it retroactively.
Navigation Path:
Setup > Quick Find: Sharing Settings > Organization-Wide Defaults > EditRole Hierarchy
The Role Hierarchy in Salesforce mirrors your organization’s reporting structure and controls vertical access to records. Users higher in the hierarchy can automatically access records owned by users below them — provided the Grant Access Using Hierarchies checkbox is enabled for the object.
For example, a Regional Sales Manager sitting above three sales reps in the hierarchy can view and edit all records owned by those reps — without needing specific sharing rules.
Navigation Path:
Setup > Quick Find: Roles > Set Up RolesImportant Note: Role Hierarchy only grants record access if OWD is not already set to Public Read/Write. If OWD is already fully open, role hierarchy has no additional effect. Also ensure the Grant Access Using Hierarchies checkbox is enabled per object in Sharing Settings.
Sharing Rules
Sharing Rules allow administrators to create automated, horizontal exceptions to OWD settings. They are ideal for cross-departmental or cross-team access — for example, giving the Marketing team read access to Accounts owned by the Sales team.
There are two types of sharing rules:
- Ownership-Based Sharing Rules: Share records based on who owns them. For instance, share all Opportunities owned by users in the West Coast Sales role with users in the Marketing role.
- Criteria-Based Sharing Rules: Share records that meet specific field criteria. For example, share all Cases where the Status field equals Escalated with the Support Management team.
Think of Sharing Rules as VIP passes that automatically open doors for specific groups — without any manual effort per record.
Navigation Path:
Setup > Quick Find: Sharing Settings > [Object] Sharing Rules > NewManual Sharing
Manual Sharing allows record owners (or users with Full Access on a record) to directly share individual records with specific users or groups. This is the most flexible option but also the least scalable.
Manual sharing is best suited for:
- One-off collaborations (e.g., temporarily sharing a record with a consultant)
- Scenarios that cannot be automated with a sharing rule
- Granting temporary access to a record without changing global settings
The Sharing button on a record is only visible when OWD is set to Private or Public Read Only and the user owns the record or has Full Access.
Scalability Warning: Manual sharing is powerful for individual cases but should not be relied upon at scale. For access patterns that repeat across many records or users, a Sharing Rule is always the better approach.
How Salesforce Evaluates Record Access
When a user tries to access a record, Salesforce does not just check one setting — it evaluates all layers simultaneously and grants the most permissive access the user qualifies for across any of the mechanisms. However, this is always constrained by the object and field-level permissions set in the user’s profile.
Here is a simplified decision flow:
- Does the user’s profile allow access to the object? If no, access is denied regardless of record-level settings.
- What does OWD say? This sets the minimum access floor.
- Does role hierarchy grant additional access? If the record is owned by a subordinate, the user inherits their access.
- Is there a sharing rule that grants access to this user or their group?
- Has the record been manually shared with this user?
- The most permissive access across all applicable mechanisms is applied
Step-by-Step: How to Configure Record Level Security in Salesforce
Step 1: Set Organization-Wide Defaults
- Navigate to Setup > Quick Find > Sharing Settings.
- Under Organization-Wide Defaults, click Edit.
- Set the appropriate access level (Private, Public Read Only, or Public Read/Write) for each object.
- Click Save. Note: Changes to OWD can take several minutes to recalculate in large orgs.
Step 2: Define Your Role Hierarchy
- Navigate to Setup > Quick Find > Roles.
- Create roles that mirror your organizational reporting structure.
- Assign users to appropriate roles via their User Records.
- Ensure Grant Access Using Hierarchies is checked in Sharing Settings for relevant objects.
Step 3: Create Sharing Rules
- Navigate to Setup > Quick Find > Sharing Settings.
- Scroll to the Sharing Rules section for the relevant object and click New.
- Choose Ownership-Based or Criteria-Based.
- Define the source (who owns the records) and target (who should receive access).
- Set the access level (Read Only or Read/Write) and save.
Step 4: Use Manual Sharing Where Needed
- Open the specific record you want to share.
- Click the Sharing button (visible only when OWD is Private or Public Read Only and you own or have Full Access on the record).
- Add the specific users or groups and define their access level.
- Save the settings.
Step 5: Audit and Monitor
After configuring record-level security, use Salesforce’s built-in tools to validate your setup. The Sharing Hierarchy button on any record shows you exactly why a user does or does not have access. Regular audits ensure your security model remains aligned with your organization’s evolving structure.
Real-World Example: Who Sees What?
Let’s look at a practical example from a fictional company called TechNova to see how all four mechanisms work together in a real scenario.
| User | Role | Mechanism Applied | What They See |
|---|---|---|---|
| Alice (Sales Rep) | Junior Sales | OWD = Private | Only her own Opportunity records |
| Bob (Sales Manager) | Regional Manager | Role Hierarchy | Alice’s records + his own |
| Carol (Marketing) | Marketing Team | Criteria-Based Sharing Rule | Accounts where Region = West |
| David (CEO) | Executive | Role Hierarchy (top level) | All records org-wide |
| Eve (Contractor) | None / External | Manual Sharing | Only the specific records manually shared with her |
This example illustrates how each mechanism serves a distinct purpose. OWD establishes the baseline, role hierarchy opens access vertically up the reporting chain, sharing rules handle cross-functional access, and manual sharing handles one-off exceptions.
Best Practices for Salesforce Admins
- Start with OWD set to Private for sensitive objects, then open access incrementally.
- Design your Role Hierarchy to mirror the real org chart, but keep it as flat as possible to avoid unnecessary complexity.
- Use Public Groups to simplify sharing rules — group users logically (by region, department, or function) before creating sharing rules.
- Prefer Sharing Rules over Manual Sharing for repeating access patterns. Manual sharing does not scale.
- Document your sharing model thoroughly. Future admins and auditors will thank you.
- Run the Sharing Hierarchy report on sample records after any major change to verify the outcome.
- Assign Profiles carefully before setting record-level security — profiles and permission sets are a prerequisite, not an afterthought.
- Audit record access regularly, especially when users change roles or leave the organization.
Common Mistakes to Avoid
- Setting OWD to Public Read/Write and then trying to restrict individual records — this cannot be done once OWD is fully open.
- Over-relying on Manual Sharing for bulk access needs — this becomes unmanageable at scale.
- Forgetting to enable Grant Access Using Hierarchies for custom objects — role hierarchy will not work without it.
- Creating too many sharing rules — this can slow down the recalculation of record access across the org.
- Not testing the sharing model from the perspective of each user role before going live.
Frequently Asked Questions
Q: What is the difference between OWD and Sharing Rules?
OWD is the global baseline that applies to every record in an object by default. Sharing Rules are specific exceptions that open up access beyond what OWD allows for defined groups or criteria. OWD restricts; Sharing Rules expand.
Q: Can a Sharing Rule restrict access that OWD has already granted?
No. Sharing Rules can only grant additional access beyond OWD — they cannot restrict access that OWD has already given. To restrict access, you must tighten the OWD setting itself.
Q: Does the Role Hierarchy always apply?
Only when Grant Access Using Hierarchies is enabled for the object in Sharing Settings. For standard objects like Accounts and Opportunities, this is typically enabled by default. For custom objects, you must enable it explicitly.
Q: Why can’t I see the “Sharing” button on a record?
The Sharing button is only visible when OWD is set to Private or Public Read Only, and you own the record or have Full Access on it. If OWD is Public Read/Write, everyone already has access and the button is hidden.
Q: Is Record Level Security the same as Field Level Security?
No. Field Level Security controls which fields a user can see or edit within a record. Record Level Security controls which records the user can access at all. Both layers work together as part of Salesforce’s overall data security model.
Conclusion & Next Steps
Record Level Security in Salesforce is one of the most powerful — and most important — tools in a Salesforce Administrator’s toolkit. By combining Organization-Wide Defaults, Role Hierarchy, Sharing Rules, and Manual Sharing, you can build a precise, scalable, and auditable data access model that protects sensitive information while enabling productive collaboration across your organization.
Mastering record-level security is not just a technical skill — it is a core competency for any Salesforce Admin aiming to build secure, compliant, and efficient CRM environments.
Ready to Master Salesforce Admin Skills?
Record Level Security is just one of many critical topics you need to ace the Salesforce Administrator Certification. If you want to learn the complete Salesforce Admin skillset — from data security to automation, reports, and beyond — in a structured, exam-focused way, check out the Salesforce Admin Certification Course at MyTutorialRack.
What you will learn:
- Complete Salesforce data security model (Org, Object, Field, and Record level)
- Hands-on practice with OWD, Role Hierarchy, Sharing Rules, and Manual Sharing
- Flows, Process Builder, Reports, Dashboards, and much more
- Exam-focused content aligned with the official Salesforce Admin certification guide
- Real-world scenarios and practice questions to build confidence
Have questions about Record Level Security in Salesforce or the certification course? Drop a comment below — we are here to help you succeed!
