Designing the sharing model is a one-shot decision for the life of the org. The steps below cover the discovery, configuration, and rollout for a new org or a sharing-model overhaul.
- Map data sensitivity per object
For each object, classify data sensitivity as high, medium, or low. Map which user populations should see each object. The decision matrix tells you which OWD makes sense before you set anything.
- Set Organization-Wide Defaults
In Setup, Sharing Settings, edit Organization-Wide Defaults. Choose Private for sensitive data, Public Read Only or Public Read/Write for shared data. Set the External default to Private even when internal is Public, especially for Experience Cloud users.
- Configure role hierarchy and Grant Access Using Hierarchies
Build the role hierarchy to reflect reporting relationships. For custom objects where records should not roll up to managers, uncheck Grant Access Using Hierarchies on the object definition. Standard objects always grant access via hierarchy.
- Add sharing rules for cross-group access
Create owner-based rules to share between groups (region to region, team to team). Create criteria-based rules to share records matching field criteria such as a Status or Type value. Stay under the 300-rules-per-object limit.
- Enable teams and territories where deal access matters
Turn on Account Teams or Opportunity Teams in Setup when ad-hoc collaborators need access to specific records. Enterprise Territory Management is the right call when geography or segment drives access patterns.
- Document the model and test in a sandbox
Write the sharing design down so future admins can read what you intended. Test the model with seed users in a full sandbox before promoting to production. Sharing recalculation can take hours on a real-data sandbox, which is itself a useful signal.
Per-object checkbox. Off means managers do not automatically see direct reports' records. Standard objects ignore this setting and always grant hierarchy access.
Independent default for Experience Cloud users. Set Private even when internal is Public Read/Write to avoid accidental external exposure.
Setup tool that pauses sharing recalc during bulk data loads. Resume the calc after the load finishes to avoid hours of locked-row errors.
- Tightening OWDs is retroactive and triggers a full sharing recalc. On a million-row object this can take hours and locks rows during the recalc.
- External OWDs are independent. Experience Cloud sites have surprised many orgs that set internal OWD to Public Read/Write and forgot the external default was still Public Read Only.
- Sharing rules have a 300-per-object hard limit. Hitting it usually means the design relies too heavily on criteria-based rules instead of role hierarchy or teams.