Salesforce’s sharing model is one of its most powerful – and most misunderstood – features. It controls which records each user can see and edit, enabling organisations to segment data access by role, territory, team, or business unit. Understanding the sharing model hierarchy – from Organisation-Wide Defaults through Role Hierarchy to Sharing Rules and Manual Sharing – is essential for Salesforce administrators configuring a deployment that handles sensitive data correctly. This guide provides a complete explanation of how sharing works, how Sharing Rules extend access, and how to diagnose sharing configuration problems.
That is why the rules matter even when they seem like a small admin setting.
In bigger orgs, the difference between clean sharing and chaotic sharing often shows up in how easy it is to collaborate without creating access problems.
If the sharing model is thought through carefully, Salesforce stays both useful and governable.
The practical benefit is that teams can work across departments while still keeping sensitive records limited to the right people.
That makes sharing rules one of the main tools for balancing security and usability in a larger Salesforce org.
Salesforce sharing rules are useful when record access needs to be expanded beyond ownership-based defaults. They help admins open access in a controlled way so teams can collaborate without giving everyone the same view of the data.
The Salesforce Sharing Model: A Hierarchy
Salesforce determines what records a user can access through a layered hierarchy. Each layer can only open access wider – not restrict it beyond what the previous layer set:
- Organisation-Wide Defaults (OWD): the baseline access level for all users – can be Public Read/Write (everyone sees everything), Public Read Only (everyone can see, only owners can edit), or Private (only the record owner and users above them in the Role Hierarchy can see the record)
- Role Hierarchy: users in higher roles can see all records owned by users in lower roles. A Sales Manager automatically sees all records owned by the reps who report to them in the hierarchy.
- Sharing Rules: rules that extend read or read/write access to groups of users – beyond what OWD and Role Hierarchy provide. Sharing Rules can be based on record criteria or record ownership.
- Manual Sharing: individual users can share specific records with other users or groups – one record at a time
- Apex Managed Sharing: programmatic sharing configured by developers using Apex code – for complex sharing logic not possible with declarative rules
Organisation-Wide Defaults (OWD): Setting the Baseline
OWD is configured per object in Setup ? Sharing Settings. The available options per object:
- Public Read/Write: all users can see and edit all records of this object type. Appropriate for objects where collaboration across the full team is needed with no data segmentation (e.g., a Shared Products catalogue).
- Public Read Only: all users can see all records but cannot edit records they do not own. Common for reference data objects.
- Private: users can only see their own records plus records shared with them through Role Hierarchy, Sharing Rules, or Manual Sharing. The most restrictive setting – used when data segmentation is required (e.g., Opportunities only visible to the owning rep and their management chain).
- Controlled by Parent: for objects with a Master-Detail relationship – access is inherited from the parent record’s sharing. If a user can see the parent Account, they can see its related Contacts and Opportunities.
The OWD design principle: set OWD to the most restrictive access level that applies to any user in the org for that object – then use Role Hierarchy and Sharing Rules to open access wider for specific groups who need it. It is architecturally impossible to restrict access below OWD; you can only open it.
Role Hierarchy: Inheriting Upward Access
Salesforce’s Role Hierarchy is a tree structure that mirrors the management hierarchy. Users in higher roles automatically have read (or read/write, depending on the OWD setting) access to records owned by users below them in the hierarchy. A VP of Sales in the top role can see all records owned by every rep in the hierarchy below.
Important: Role Hierarchy is about record ownership visibility – it grants access to records owned by subordinate users. It does not control what the user can do with those records (read vs. read/write depends on OWD and other settings).
Sharing Rules: Extending Access Beyond the Hierarchy
Sharing Rules open access to groups of users who would not otherwise have visibility based on OWD and Role Hierarchy. There are two types:
Ownership-Based Sharing Rules
Grant access to records based on who owns them. “Share all Accounts owned by the EMEA Role with the Global Key Account Management team (a Public Group).”
Configuration: Setup ? Sharing Settings ? [Object] Sharing Rules ? New ? Based on record owner
- Select the record owners (a role, a role and subordinates, a public group, a territory)
- Select who gets access (a role, a role and subordinates, a public group)
- Select the access level (Read Only or Read/Write)
Criteria-Based Sharing Rules
Grant access to records based on field values. “Share all Accounts with Industry = Healthcare with the Healthcare Specialist team (a Public Group).”
Configuration: Setup ? Sharing Settings ? [Object] Sharing Rules ? New ? Based on criteria
- Define filter criteria (field, operator, value)
- Select who gets access (a role, a public group, or a territory)
- Select the access level (Read Only or Read/Write)
Criteria-based sharing is evaluated when a record is created or when a field value changes to meet the criteria – the sharing is applied dynamically as records match or unmatch the criteria.
Public Groups: The Foundation of Sharing Rules
Public Groups are collections of users, roles, or territories that can be referenced in Sharing Rules, List View visibility, and Manual Sharing. Creating a Public Group for every logical team (EMEA Sales, Healthcare Specialists, Key Account Management) makes Sharing Rules much more manageable – when team membership changes, only the Public Group needs to be updated, not every Sharing Rule individually.
Create Public Groups at: Setup ? Users ? Public Groups ? New
Manual Sharing: Record-Level Override
Any record owner (or admin) can manually share a specific record with a specific user or group using the Sharing button on the record page (if enabled in the page layout). Manual sharing is not scalable – it requires individual action for each record – but it is appropriate for one-off exceptions: “share this specific Opportunity with the legal team for contract review.”
Common Sharing Configuration Mistakes
- Setting OWD too permissively: starting with Public Read/Write and trying to restrict access for specific records using workarounds. The correct approach is to set OWD to Private and open access with Sharing Rules. Restriction below OWD is not possible declaratively.
- Role Hierarchy that does not match the management structure: if the Role Hierarchy does not reflect who manages whom, visibility inheritance is incorrect – managers cannot see their team’s pipeline
- Too many Sharing Rules: Salesforce has a limit of 300 Sharing Rules per object per org. More than ~20 Sharing Rules on a single object often indicates a sharing model that should be redesigned using Territories or Public Groups more strategically
- Forgetting to recalculate sharing: after changes to OWD or Role Hierarchy, Salesforce may require a sharing recalculation job (Setup ? Sharing Settings ? Recalculate). Very large orgs can experience delays during recalculation that affect user access temporarily.
Is Salesforce easy to learn for beginners?
Salesforce has a learning curve, but its official free training platform Salesforce Trailhead provides structured paths from beginner to advanced. Most users handle day-to-day tasks within 2-4 weeks. Admin and developer skills take 3-6 months to develop proficiently.
What are the biggest Salesforce mistakes to avoid?
Top mistakes include: over-customizing before understanding your process, skipping user training, importing dirty data without cleansing, and not establishing naming conventions. Avoid these four and your implementation will be significantly more successful.
How often does Salesforce release new features?
Salesforce releases major updates three times per year in Spring, Summer, and Winter releases. Salesforce previews upcoming features in sandbox environments 4-6 weeks before each release.
Does Salesforce offer customer support?
Yes. Support is available via chat, email, and phone depending on your plan tier. Enterprise plans include dedicated customer success managers. The Salesforce Trailblazer Community offers extensive peer and official support.
Can Salesforce integrate with other business tools?
Yes. Salesforce AppExchange offers 7,000+ apps. Common integrations include Slack, DocuSign, Zoom, and ERP systems via MuleSoft.
Diagnosing Sharing Issues: The Record Access Analysis Tool
When a user reports they cannot see a record they should be able to access, or can see a record they should not, Salesforce provides the Record Access Analysis tool (available from the record’s Share button, visible to admins):
- Open the record in question
- Click the Sharing button
- Click Expand List to see all users who have access to this record and why (Role Hierarchy, Sharing Rule, Manual Share, Team membership)
For a more systematic audit, the Salesforce Optimizer or the Security Health Check (Setup ? Security ? Health Check) identifies sharing configurations that may be overly permissive or incorrectly configured.
Common Challenges with Salesforce Sharing Rules and How to Solve Them
Problem: Getting Your Team to Consistently Use Salesforce
Adoption gaps occur when teams revert to old habits after initial training. Fix: Identify the 2-3 daily workflows where Salesforce adds the most value for your specific role. Focus training on those workflows first. Use Salesforce in-app guidance to provide contextual help at the moment of need rather than relying solely on one-time classroom training.
Problem: CRM Data Quality Degrading Over Time
CRM data decays at approximately 30% per year as contacts change roles and companies. Fix: Schedule a quarterly data quality audit. Use Salesforce deduplication tools to merge duplicate records. Establish data entry standards enforced through validation rules. Consider a data enrichment tool like Clearbit or ZoomInfo to update stale records automatically.
Problem: Salesforce Reports Not Matching Actual Business Results
Reports are only as accurate as the data entered. Discrepancies between CRM reports and actual revenue indicate data entry gaps. Fix: Audit closed-won records against actual invoices monthly. Make CRM data the source of truth for commission calculations so reps have a direct incentive to enter accurate data.
The best sharing setup is the one that grants access only where it is needed. If the rules are too broad, the system becomes harder to govern.