Why a Retrospective Sharing Model is Harder Than a Well-Built One
The typical problem doesn't surface in the first month. It emerges when a regional sales manager notices they can see an opportunity from a competitor's territory, or when a service rep opens a VIP customer's case that should only be accessible to a dedicated team. Both scenarios are a direct result of a reversed workflow: defining objects and fields first, and only at the very end asking who should actually see what.
The visibility model in Salesforce is constructed from layers that operate in concert, not independently: Organization-Wide Defaults (OWD) establish the most restrictive baseline, Role Hierarchy adds vertical access based on the managerial structure, Sharing Rules open up horizontal access based on business criteria, Teams and Manual Sharing address individual cases, and Apex Managed Sharing comes into play when the logic is too complex to be expressed using static rules. This order is crucial: every layer chosen prematurely creates technical debt that is difficult to untangle, because permissions already granted are perceived as an existing right.
Mapping the Layers and When Each is Appropriate
| Layer | What it Solves | When to Choose It | Risk of Incorrect Choice |
|---|---|---|---|
| OWD | The baseline: who can't see anything by default | Always defined, usually Private for sensitive objects | An overly open OWD renders all other layers redundant |
| Role Hierarchy | Vertical access for a manager to subordinates' information | When the management structure also reflects the need for data oversight | A "political" hierarchy that doesn't align with actual data ownership |
| Sharing Rules | Opening horizontal access based on fixed criteria (role, group, field value) | A cross-hierarchy team needing access to the same record type | A multitude of overlapping rules making it hard to determine who opened what |
| Public Groups | Grouping users for sharing purposes, irrespective of the hierarchy | When a workgroup doesn't align with a single organizational role | Groups that aren't updated when employees change roles |
| Account/Case Teams | Dynamic access to a single record based on its team composition | When each customer or case has a unique, changing team | Manual maintenance that is forgotten when the team changes |
| Territory Management | Assigning access based on dynamic, multi-dimensional rules | Variable assignment based on several attributes simultaneously, parallel access for multiple reps | Maintenance complexity not justified below a certain organizational threshold |
| Apex Managed Sharing | Sharing derived from dynamic logic that cannot be expressed statically | Criteria dependent on calculation, external events, or field combinations | Unmonitored code that continues to run after business requirements change |
OWD: The Decision That Determines All Others
OWD isn't just a technical security setting—it's an organizational statement about who truly owns the information. The practical rule: set OWD based on the most stringent requirement truly needed, and then open it up using Sharing Rules, not the other way around. The reason is that expanding access specifically is easy and documented, whereas restricting existing access requires organizational communication, because users perceive a loss of access as an infringement, even if it's a correction of a historical error.
A point that often doesn't receive enough attention: OWD is set separately for each object, and dependent objects (Master-Detail) inherit visibility from the primary object. When building a new data model, examine the full dependency chain before setting OWD—otherwise, a "secondary" object mistakenly configured as Public can expose information from the primary object through it.
Role Hierarchy vs. Actual Management Structure
The most common mistake is duplicating the organizational chart into the Role Hierarchy as-is, without verifying if it accurately reflects the flow of data ownership. A regional manager needs to see their team's opportunities—that's a managerial role. But a CFO doesn't automatically need to see every service case just because they are high up in the overall hierarchy; if such a need exists, it should be addressed with a targeted Sharing Rule, not an overly broad hierarchy.
A sharing hierarchy separated from the organizational reporting hierarchy is a legitimate and often preferable solution, especially in organizations with a matrix structure where managerial reporting doesn't align with customer data ownership.
Decision Matrix: What Triggers Each Sharing Mechanism
- Need varies by persistent, predictable role → Role Hierarchy.
- Need is shared by a cross-functional workgroup → Public Group + Sharing Rule.
- Need varies by team composition on a single record → Account Team or Case Team.
- Need depends on a combination of dynamic conditions (geography, product, customer size) → Territory Management.
- Need is derived from a calculation, external event, or condition that cannot be expressed statically → Apex Managed Sharing.
- Need is a specific, temporary exception for a single record → Manual Sharing, with oversight and documentation.
This matrix should be drafted before working with the tools, not concurrently—otherwise, a mechanism will be chosen based on what the development team is familiar with, rather than what suits the requirement.
Illustrative Scenario: An Industrial Equipment Manufacturer with Three Sales Channels
Imagine a hypothetical industrial equipment manufacturer with roughly 180 Salesforce users, operating through three channels: direct sales by geographical region, sales through distributors, and sales to global strategic accounts managed concurrently by several reps in different countries.
An initial attempt to use only Role Hierarchy failed: a global strategic account didn't belong to a single regional hierarchy, and a rep in Germany couldn't see updates from their colleague in Brazil on the exact same account. The chosen solution combined three layers: OWD for Account and Opportunity was set to Private; Role Hierarchy was used for regular managerial access within each region; and for strategic accounts, a dynamic Account Team was configured to update automatically via Flow when the "Strategic Account Owner Region" field changed. Distributors received separate access through a Sharing Rule based on a dedicated Public Group, to prevent exposure to direct sales accounts.
The result: Sharing Recalculation time remained stable because most access is derived from a static structure (Role, Public Group), and only a minority of accounts—the strategic ones—depend on dynamic updates. The core lesson: there isn't one "correct" mechanism for the entire organization; rather, the mechanism should be tailored to the type of dependency for each sub-group of records. Further discussion on selecting integration patterns and a supportive data model is available in the CRM Architecture Guide.
Specific Risks in Visibility Planning and Preventive Actions
| Risk | How It Manifests | Preventive Action |
|---|---|---|
| OWD "temporarily" open during pilot phase | The openness persists after the system goes live into production | Establish a predefined closure date and document it as a Go-Live item, not a recommendation |
| Multiple overlapping Sharing Rules | It's impossible to definitively know why a user sees a particular record | Standardized naming for each rule that includes the business reason, and periodic review of unused rules |
| Apex Sharing without load testing | Sharing calculation delays as data volume grows | Conduct load testing on Sharing Recalculation before doubling record volume in production |
| Sharing hierarchy copied from a political organizational hierarchy | Managers see data they have no business need for | Separate the Role hierarchy for sharing purposes from the official reporting hierarchy when they are not identical |
| Manual Sharing accumulates without ownership | Exceptional permissions remain active after the reason for sharing is no longer relevant | Implement an expiration process or quarterly review of manual shares |
| User role change without Public Group updates | Old access remains open, and new access is missing | Integrate group and role updates as a single step in the employee status change process |
Checklist Before Finalizing the Sharing Model
- ☐ OWD configured for the most restrictive required state, not for development convenience
- ☐ Dependency chain between Master-Detail objects reviewed against the primary object's OWD
- ☐ Role Hierarchy reviewed against actual data ownership, not just an organizational chart
- ☐ Each Sharing Rule has documented business reason and an owner responsible for its validity
- ☐ Assessed whether Territory Management is actually needed or if it introduces unnecessary complexity
- ☐ Apex Sharing code tested under realistic data volume, not just in a small Sandbox environment
- ☐ Process in place for updating Public Groups and permissions upon role change or termination
- ☐ Defined a periodic review cadence for Manual Sharing and inactive Sharing Rules
- ☐ Impact of the sharing model on report performance and large batch runs analyzed
- ☐ Response plan in place for discovering over-exposure in production
How to Know the Model Withstands Load
The first metric is Sharing Recalculation time after structural changes—a consistent increase over time indicates the model is approaching unmanageable complexity. The second metric is the number of support requests for "I lack access" versus "I have unnecessary access"—a sharp skew in one direction suggests that OWD or Sharing Rules are not properly calibrated. A third metric, particularly crucial in organizations with multiple systems, is the alignment between Salesforce permissions and permissions in synchronized systems—especially concerning event-driven integration architecture, as described in the Salesforce Event-Driven Architecture Guide.
In organizations operating multiple Orgs, the sharing model issue often intersects with the question of whether more than one production environment is even necessary—the full discussion can be found in Salesforce Single Org vs. Multi Org, and in selecting compatible integration patterns in the Salesforce Integration Patterns Guide.
Summary
A good sharing and visibility model isn't measured on launch day—it's measured as the organization grows, when a user changes roles, and when someone asks, "Why can't I see this?" The way to achieve this is not to pick one tool and apply it to everything, but rather to map each group of records according to its type of dependency—permanent, horizontal, dynamic, or exceptional—and choose the appropriate mechanism for each. A closed OWD by default, a Role Hierarchy reflecting true ownership, Sharing Rules with documented reasons, and Apex Sharing only when the logic justifies it—this is the combination that endures even when the organization doubles in volume and complexity.