Salesforce Fundamentals: Part 5 - Sharing Data

Published 26/09/2025

---

With a solid foundation in data management now in place, you’re ready to explore one of the most important pillars of the Salesforce platform: how access to that data is controlled. Record‑level security determines who can see what, who can edit what, and how information flows across teams. It underpins every scalable, compliant Salesforce implementation.

This section breaks down the full sharing model step by step, from Organization‑Wide Defaults and the Role Hierarchy to Sharing Rules, Manual Sharing, Apex Managed Sharing, and Restriction Rules. By the end, you’ll understand not just how these mechanisms work, but how to combine them to design secure, intuitive access patterns that support your business rather than slow it down.

Think of this as learning the “rules of visibility” inside Salesforce.

---

🛡️ Salesforce Security — Sharing Rules, OWD, Role Hierarchy

Understanding the Salesforce security is crucial for protecting your organization. Salesforce employs a comprehensive layered security approach to safeguard its platform, user data, and applications. This methodology ensures multiple, overlapping defense measures are in place to minimize risk and address a wide variety of threats and vulnerabilities.

Layered security, also known as defense-in-depth, incorporates several levels of protection. If one layer fails, others are in place to prevent unauthorized access or misuse. In Salesforce, this approach blends physical, network, application, and data-level controls to create a robust security framework.

Salesforce infrastructure is hosted in highly secure data centers ensuring Physical Security. Firewalls, intrusion detection and encrypting data in transit help cover Network Security. Authentication, Authorization, Access Control and Session Management are some tools that help Application Security e.g. who can access your Salesforce org and what users have access to see and do. Object level, field level and record level access are the main tools of Data Security. Further security can be added by operational measures and user education.

While Physical Security & Network Security layers are mostly controlled by Salesforce, Application Security and Data Security are as much controlled within the organization.

This section focuses on the Record Level security part of Data Security. It covers two categories of access control:

Opening access: Organization-Wide Defaults (OWD) → Role Hierarchy → Sharing Rules → Manual Sharing → Apex Managed Sharing

Restricting access: Restriction Rules

Record‑level security in Salesforce is built on a layered, mostly additive model. You start with the most restrictive baseline and then open access only where business needs require it. Understanding how these layers interact is essential for designing a secure, predictable data‑sharing model.

🗄️ Organization-Wide Defaults (OWD)

Organization-Wide Defaults (OWD) set the baseline level of access that users have to records they don’t own. It should be the most restrictive setting for your data security needs.

OWD Access Levels

Private: Only record owner and users above them in role hierarchy can access
Public Read Only: All users can view but only owner can edit
Public Read/Write: All users can view and edit records
Controlled by Parent: Access determined by parent object’s sharing settings

Setting Up OWD

Setting up Organization-Wide Defaults (OWD) can be done by navigating to Security Settings in the Setup menu

Step-by-Step Process:

1. Click Edit in the Organization-Wide Defaults section
2. For each object, select the appropriate Default Internal Access
3. Set the Default External Access
4. Configure Grant Access Using Hierarchies checkbox
5. Click Save

Understanding “Grant Access Using Hierarchies”

This critical checkbox controls whether users higher in a hierarchy automatically gain access to records owned by users below them. It is always enforced for standard objects, and optionally configurable per custom object. Use it to support managerial oversight; disable it (custom objects only) to enforce strict, non-hierarchical segmentation.

• Checked: Users higher in role hierarchy can access subordinates’ records
• Unchecked: Only record owner and explicit shares get access

You cannot modify this setting for standard objects, it is always enabled.

When enabled and the organization-wide default (OWD) is restrictive, users above others in the Role Hierarchy gain implicit access to records owned by users below them. The level of access inherited matches the maximum allowed by OWD and other sharing mechanisms.

Examples of how OWD interacts with hierarchy-based access:

• If OWD is Private, a higher-role manager gains at least Read access, and usually the same access the record owner has, limited by the manager’s own object permissions.
• If OWD is Public Read Only, a higher role can gain Edit access when the hierarchy model and their permissions allow it.

Key nuance: Hierarchy-based sharing never exceeds a user’s object-level permissions. If a manager lacks Edit permission on the object, they cannot edit child records even if hierarchy access would otherwise permit it.

🪜 Role Hierarchy

The Salesforce Role Hierarchy is a foundational security and data access mechanism that controls record visibility based on a defined role structure. It works alongside your Organization‑Wide Defaults (OWD) to decide which records a user can see, report on, and potentially edit across your org.

By default, users positioned higher in the role hierarchy automatically gain visibility to records owned by or shared with users below them, though this behaviour can be disabled for custom objects. This creates a “vertical” data access model, managers can see their team’s data, but peers in different branches cannot see each other’s records.

How Role Hierarchy Works

• Upward, not sideways: Users at the same level or in different branches do not gain visibility into each other’s records.
• Extends the OWD baseline: The hierarchy can only add access above what OWD allows. If OWD is Private, managers gain visibility into subordinate records. If OWD is Public Read Only, hierarchy does not automatically grant edit access.
• Custom object exception: For custom objects, you can disable hierarchy‑based access entirely, preventing any upward visibility for that record type.

Best Practices for Role Design

• Align with Data Access, Not the Org Chart: Build roles around who needs to see what, not reporting lines or job titles. Multiple job titles can share a single role if their visibility needs are identical.
• Keep it Flat: Minimise hierarchy depth and total role count. Only create roles that serve a current, defined security purpose. Deep hierarchies slow down sharing recalculations and make maintenance harder. Never create empty or placeholder roles just in case.
• Assign Every User to a Role: Users without a role won’t appear in reports, forecast roll-ups, or other role-based displays. However, if a user owns more than 10,000 records, either leave them without a role or place them at the top of the hierarchy in their own branch to avoid performance issues.
• Use Descriptive Names: Clear, purposeful role names make the hierarchy easier to understand and maintain.
• Document Your Hierarchy: Maintain documentation covering the purpose, intended users, and data access scope of each role. This becomes essential as your org grows and team members change.

🧬 Sharing Rules

Sharing rules are a powerful tool in your Salesforce security toolkit to open up access to records. Sharing rules act as automatic exceptions to Organization-Wide Defaults (OWD) that grant additional access to records for specific groups of users. They allow you to expand access in a targeted way while keeping your broader data security model intact.

They work by identifying records that meet specific criteria and then sharing those records with designated users or groups. Importantly, sharing rules can only grant more access than the OWD setting, they cannot restrict access that users already have through other means.

Once configured, a sharing rule creates an ongoing and automatic sharing relationship. Unlike manual sharing, which requires individual record-level actions, sharing rules apply continuously and dynamically. As new records are created or existing ones are updated to meet the criteria, Salesforce automatically applies the rule, ensuring consistent and scalable access management.

Salesforce offers two distinct approaches to building sharing rules, each suited to different business scenarios.

Ownership-Based Sharing Rules grant access based on who owns the record. These rules follow a straightforward logic: if a record is owned by members of one group, share it with members of another group.

Criteria-Based Sharing Rules grant access based on field values within the record itself, regardless of who owns it. These rules examine the actual data in the record and make sharing decisions accordingly. This method provides more flexibility and supports complex business requirements where ownership doesn’t determine who needs access.

When to use each

Use ownership-based rules when access needs follow who owns the record. Use criteria-based rules when access should be driven by the data itself For example, sharing all Accounts in a specific region with a regional sales team, regardless of who created them.

How Sharing Rules Work in Practice

When you create a sharing rule, you define three essential components:

• What records to share (the criteria)
• Who to share them with (the target group)
• What level of access to grant (Read Only or Read/Write).

The “what to share” portion differs between the two rule types. For ownership-based rules, you select a public group, role, role and subordinates, or territory that represents the record owners. For criteria-based rules, you build filter logic using field values, similar to creating a report filter or list view. You can combine multiple criteria with AND/OR logic to precisely target the right records.

Criteria-based limitation

Filter criteria cannot reference lookup fields, formula fields, or encrypted fields; only standard and custom fields with direct values on the record itself.

The “who to share with” portion is consistent across both types. You can share records with public groups, roles, roles and subordinates, territories, or roles and internal subordinates (which includes both role hierarchy members and their subordinates in the internal organization). This flexibility lets you align sharing with your organisational structure.

The access level determines what recipients can do with the shared records. Read Only access allows users to view records and related information, while Read/Write access additionally permits editing (assuming the user’s profile or permission sets grant Edit permission on the object). The access level you grant through sharing rules is bounded by the user’s object-level permissions. If someone lacks Edit permission on Accounts, a Read/Write sharing rule won’t give them edit capability.

Navigate to Sharing Rules: Setup → Security → Sharing Settings

Sharing Rule Considerations

• Cannot Restrict: Sharing rules only grant additional access, they cannot take it away.
• Performance Impact: Too many rules can slow down the system, keep rules lean.
• Recalculation: Changes trigger automatic sharing recalculation accross affected records
• Limits: Each object has limits on the number of sharing rules, plan accordingly before building a complex sharing model

Note: Restriction Rules provide the opposite, permanently filtering records users could see via sharing, these are an advanced feature introduced in Winter 22 that we are not covering here.

Best Practices for Designing Sharing Rules

Start with a clear understanding of your business requirements before creating any sharing rules. Document who needs access to what records and why. This documentation becomes invaluable as your organisation grows and your sharing model becomes more complex.

Keep your sharing rules as simple as possible while still meeting business needs. Each sharing rule you create adds to system processing overhead and increases maintenance complexity. Before creating a new rule, ask whether adjusting your OWD settings, modifying your role hierarchy, or using teams might accomplish the same goal more efficiently.

Use descriptive, consistent naming conventions for your sharing rules and public groups. A name like “Share Western Region Opps with Sales Ops — Read Only” immediately communicates what the rule does, while “Sharing Rule 1” tells you nothing. Good naming practices become critical when you’re troubleshooting access issues or auditing your security model months or years later.

Test your sharing rules thoroughly before deploying them to production. Create test users in the appropriate groups, create test records that match your criteria, and verify that access works as expected. Remember to test both positive cases (users who should gain access) and negative cases (users who should not gain access).

🤝 Manual Sharing

Manual sharing lets record owners (or those above them in the role hierarchy/admins) grant one-off access to individual records when OWD is Private or Public Read Only. It’s quick for exceptions but creates clutter if overused so should be used sparingly.

When to Use Manual Sharing

• One-off Collaborations: Temporary project access that wasn’t planned for in your sharing model
• True Exceptions: Situations that sharing rules can’t or shouldn’t cover
• Urgent Needs: Immediate access required without Setup changes.

How Manual Sharing Works

1. Share Button: Available on record detail pages when OWD is restrictive (add to Lightning page layout via Object Manager if missing)
2. Who can share: Record owner, role hierarchy superiors, admins, or users with full Modify All permissions.
3. Access Levels: Read Only or Read/Write (can’t restrict existing access)
4. Automatic Removal: Sharing is removed if record owner changes so re-share if needed. Exceptions exist for parent account changes by qualified users.

Manual Sharing Best Practices

• Avoid Over-reliance: Favor sharing rules/roles for patterns; manual shares don’t scale.
• Document Decisions: Keep track of why manual shares were created
• Regular Cleanup: Use reports or Setup Audit Trail to spot/review old shares and remove unnecessary manual shares
• Performance Limits: Maximum 10,000 manual account shares per user recommended (soft limit)

💻 Apex Managed Sharing

Apex Managed Sharing gives developers programmatic control over record access, enabling sharing logic that goes beyond what declarative tools can express. It is the right choice when your sharing requirements depend on complex business logic, external system data, or conditions that can’t be captured with field-based criteria.

How Apex Sharing Works

Apex Managed Sharing works by inserting records directly into the object’s share table (for example, AccountShare for Accounts, or MyObject__Share for custom objects). Each share record defines the record being shared, the user or group receiving access, the access level, and a row cause which is a unique identifier that labels the source of the share and prevents Salesforce from deleting it during recalculations.

AccountShare share = new AccountShare();
share.AccountId = accountId;
share.UserOrGroupId = userId;
share.AccountAccessLevel = 'Edit';
share.OpportunityAccessLevel = 'Edit';
share.RowCause = Schema.AccountShare.RowCause.Manual;
insert share;

Custom Row Causes: For custom objects, you can define your own row causes, this is recommended as allows Salesforce to distinguish your programmatic shares from manual ones and preserves them through recalculation events.

When to Use Apex Managed Sharing

• Sharing logic depends on related records, external data, or complex multi-condition rules that criteria-based sharing cannot express
• Access needs to be granted or revoked dynamically based on business process events
• You need fine-grained control over exactly when and why access is granted, with full auditability

Key Considerations

• Maintenance overhead: The code requires updating if sharing requirements change
• Recalculation: Custom row causes survive recalculation; Manual row cause shares may not
• Testing: Apex sharing logic must be covered by unit tests; test both grant and revoke paths
• Requires developer involvement: Not configurable by admins and changes need deployment

🧱 Restriction Rules

Restriction Rules work in the opposite direction to sharing rules. Instead of granting additional access, they filter records that users would otherwise see based on your OWD and sharing model. They allow you to show a subset of records to specific users without changing the underlying sharing configuration.

Think of it this way: Sharing rules punch holes upward through OWD to let more in. Restriction rules punch holes downward to filter out records the user technically has access to.

How Restriction Rules Work

A restriction rule has two components that work together: User Criteria and Record Criteria.

User Criteria defines who the rule applies to. You can target users based on profile, role, or other user fields (using the “Current User” type), or target users who hold / don’t hold a specific custom permission. Users who don’t match the user criteria are unaffected and continue to see records normally.

Record Criteria defines which records the targeted users are allowed to see. When the rule is active, Salesforce takes all the records a user would normally have access to via OWD, sharing rules, and other sharing mechanisms, then filters that set down to only the records matching your record criteria. If a user has a direct link to a record that the restriction rule now hides from them, they’ll see an access error.

For example: a restriction rule on a custom object could target users with the “Support Tier 1” profile (User Criteria) and only allow them to see records where  Tier__c = 'Tier 1 (Record Criteria) even if OWD would otherwise grant them visibility across all tiers.

Important: Restriction rules currently support only the Equals operator and do not support formula fields in either criteria type.

When to Use Restriction Rules

• You need to segment visibility within a broadly open OWD without rebuilding your sharing model
• Different teams should only see their own subset of records without using Private OWD and complex sharing rules
• You want a cleaner, more maintainable alternative to complex criteria-based sharing rule combinations

Key Considerations

• Not Universally available: Restriction rules are available on custom object and some standard objects like Accounts, Cases, Contacts, Leads, Opportunities but not all standard objects.
• Limit: Up to 2 restriction rules per object

📚 Further Reading & Resources

This section has covered the core components of record-level security, but the following resources are worth bookmarking for reference or further exploration.

Protect Your Data in Salesforce provides a hands-on Trailhead project that walks you through configuring login controls, OWD, sharing rules, and role hierarchy in a guided playground environment. A good practical introduction before diving deeper into the concepts covered above. And the Data Security Module recommended previously also covers Role Hierachy and Sharing Rules

Protect Your Data in Salesforce Secure your Salesforce org by controlling login and data access for users.

Data Security Module Control access to data using point-and-click security tools.

Official reference documentation

• Sharing Rules — Salesforce Help
• Controlling Access Using the Role Hierarchy — Salesforce Help
• Restriction Rules - Salesforce Developer Guide
• Manual Sharing — Salesforce Help
• Platform Sharing Architecture - Achitecture Center

---

🏆 Best Practices

Security Design Principles

Principle of Least Privilege

Start with the most restrictive settings and open access deliberately. Grant the minimum access needed for a user to do their job. Regularly audit to remove access that is no longer required.

Layered Approach

Each component of the record-level security model serves a distinct purpose. Use them in sequence and resist the temptation to use a higher layer to compensate for a poorly configured lower one. If your OWD is wrong, fix the OWD.

Security Auditing

Regular Reviews

Audit your sharing model after significant org changes e.g. user onboarding/offboarding, team restructures, new business processes, or major releases. Don’t wait for an access complaint to discover your model has drifted.

• User Access Verification: Test with real user personas using Login As. Checking the configuration in Setup alone is not sufficient
• Sharing Calculation Performance: Watch for delays in sharing recalculations, especially after bulk data loads or large sharing rule changes.
• Documentation: Keep your security model documentation current; an undocumented sharing model becomes unmaintainable quickly

Sandbox First

Always test sharing model changes particularly OWD changes and new sharing rules in a sandbox before deploying to production. OWD changes in particular trigger a full sharing recalculation across the entire org and can have unexpected downstream effects.

🔧 Troubleshooting Common Issues

Users Can’t Access Expected Records

Before working through the checklist below, use the Sharing Hierarchy tool first, it shows exactly who has access to a specific record and why, without guesswork.

Within any record → Actions menu → Sharing Hierarchy → click View next to any user

The Sharing Hierarchy page shows the users, groups, roles, and territories that have access to the record. In Lightning Experience, clicking View shows reasons for access, including the name of the sharing mechanism that grants access.

Note

If you don’t see the Sharing Hierarchy option and you have the right permissions, make sure that it’s added to the page layout. You can also try this URL:

/lightning/r/<ObjectApiName>/<RecordId>/recordShareHierarchy

If that doesn’t resolve it, work through these in order:

1. Object Permissions: Verify the user has at least Read access on the object via their profile or permission sets
2. OWD Settings: Confirm the baseline access level for the object, if set to Private, the user needs an explicit share
3. Role Hierarchy: Check the user’s role position relative to the record owner
4. Sharing Rules: Look for rules that should apply, check both ownership-based and criteria-based rules, and verify the user is in the target group
5. Public Group Membership: Confirm the user is a member of any public groups referenced in sharing rules
6. Manual Shares: Check whether an individual record share exists or has been removed

Users Can See Records They Shouldn’t

Less common than access being too restrictive, but harder to diagnose because the cause isn’t always obvious. Check each of these as independent possibilities:

• OWD too open: If OWD is Public Read Only or Public Read/Write, all users can see all records by default, check whether the baseline should be tightened.
• Sharing Rule too broad: Review the sharing rule criteria and membership, it may be targeting a group that’s wider than intended.
• Role Hierarchy: A user sitting higher in the hierarchy than expected will inherit visibility from below
• Restriction Rules: If tightening OWD isn’t practical, consider whether a Restriction Rule can filter visibility down to only the records the user should see

Common Error Messages

⚠️ Insufficient Privileges

This message can surface for several different reasons, don’t assume it’s purely a sharing issue:

• Missing object-level Read permission on the profile or permission sets
• Missing record-level access (OWD Private with no applicable share)
• A Visualforce page or Apex class without the correct without sharing / with sharing  context
• Field-level security blocking a required field

⚠️ You don’t have the level of access necessary

This message appears when a user tries to perform an action on a record but their current permissions don’t allow it. It’s Salesforce’s generic way of saying “Your profile, permission sets, role, or sharing settings don’t give you enough access to do this.” Because it’s generic, it can show up in several different scenarios, work through the access checklist above

Performance Issues

Slow Sharing Calculations

- Symptoms: Long delays when saving records, changing ownership, or modifying sharing rules
- Causes: Large number of sharing rules, deep role hierarchies, high data volumes
- Solutions: Consolidate sharing rules, flatten role hierarchy, simplify sharing criteria logic, avoid triggering OWD changes during business hours.

Sharing Recalculation Timeouts

- Symptoms: Sharing changes don’t take effect immediately
- Causes: Large data volumes combined with a complex sharing model. - Solutions: Schedule sharing model changes during off-peak hours; for large orgs, consider breaking changes into smaller batches

Tip

For persistent or complex access issues, enable a Debug Log for the affected user and reproduce the issue. The log will show exactly which sharing and permission checks are being evaluated.

---

🔍 Practical Examples

Example 1: Basic Sales Hierarchy (Role Hierarchy Only)

Business Need

Reps see own opps; managers see team opps; VP sees all.

Configuration

OWD Settings: Opportunities = Private
Role Hierarchy:

VP Sales
├── West Manager
│ ├── Rep A
│ └── Rep B
└── East Manager
  ├── Rep C
  └── Rep D

Result

Rep A and Rep B can only see their own opportunities. West Manager sees all opportunities owned by Rep A and Rep B. VP Sales sees all opportunities across both regions. No rep can see another rep’s opportunities.

Example 2: Cross-Region Collaboration (Sharing Rules)

Business Need

Marketing reads high-value accounts (> $1M revenue).

Configuration

OWD Settings: Accounts = Private
Criteria Sharing Rules:
- Criteria: Annual Revenue > 1,000,000
- Share with: Marketing Group (Public Group)
- Access: Read Only

Result

Marketing team members can view but not edit any Account with Annual Revenue over $1M, regardless of who owns it. Sales reps below the account owner in the hierarchy are unaffected. Marketing sees no other accounts.

Example 3: Regional Sales Structure

Business Need

- Regional teams should share accounts within their region
- National accounts team should see all accounts
- No cross-regional visibility for regular sales reps

Configuration

OWD Settings: Accounts = Private
Role Hierarchy:

National Sales Director
├── Regional Manager North
│ ├── Sales Rep North 1
│ └── Sales Rep North 2
├── Regional Manager South
│ ├── Sales Rep South 1
│ └── Sales Rep South 2
└── National Accounts Manager
  ├── National Account Rep 1
  └── National Account Rep 2

The role hierarchy alone gives managers visibility upward, but peers within the same region can’t see each other’s accounts under a Private OWD. The owner-based sharing rules below solve this by sharing each region’s records back with the same group, ensuring teammates can collaborate on each other’s accounts.

Sharing Rules:

1. Owner-Based Rule: “North Region Sharing”
    — Owned by: North Region Sales (Public Group)
    — Share with: North Region Sales (Public Group)
    — Access: Read/Write

2. Owner-Based Rule: “South Region Sharing”
    — Owned by: South Region Sales (Public Group)
    — Share with: South Region Sales (Public Group)
    — Access: Read/Write

3. Criteria-Based Rule: “National Accounts Visibility”
    — Criteria: Account Type = “National”
    — Share with: All Sales (Public Group)
    — Access: Read Only

Result

North reps can read and edit all North accounts. South reps can read and edit all South accounts. Neither region can see the other’s accounts. All sales staff can view but not edit accounts flagged as National type. The National Sales Director sees everything via the role hierarchy.

---

🎯 Final Thoughts

This guide provides the foundation for understanding Salesforce record-level security. As you gain experience, you’ll develop intuition for designing sharing models that balance security with usability. Remember: the best security model is one that enables your business while protecting your data.

Mastering data management and security sets you up for scalable, compliant Salesforce implementations, critical for enterprise work.

🚀 Next steps

The Fundamentals series is now complete. Next, the Mastering Salesforce Administration track takes you deeper into running and maintaining real orgs. Start with Org Health & Monitoring, where you’ll build the habits and tools that keep an org stable, observable, and easy to support over time.

📚 Resources

Protect Your Data in Salesforce Secure your Salesforce org by controlling login and data access for users.

Data Security Module Control access to data using point-and-click security tools.