Designing the sharing model is an architectural exercise that spans business requirements gathering, OWD selection, rule design, role hierarchy alignment, and ongoing maintenance. The workflow below covers the standard sequence for a new sharing design.
- Document business sharing requirements
Talk to each stakeholder group about what records they need to see and edit. Capture the requirements as a matrix: object, user group, access level (read, edit, none). Identify cross-team scenarios (sales engineers need visibility to all closed-won deals, partner managers need visibility to deals in their territory). Document any compliance constraints (HR data is private, financial data is restricted to specific roles). This requirements document becomes the design foundation; without it, the sharing model is built on assumptions that bite later.
- Set Organization-Wide Defaults intentionally
From Setup, navigate to Sharing Settings. Set the OWD for each major object based on the design. Start more restrictive than you think you need; opening up sharing later is easier than tightening it. Private is the standard starting point for sensitive objects (Account, Opportunity, Case); Public Read Only is appropriate for reference data. Save the OWD changes and confirm in sandbox that users see the expected records (or do not see records they should not).
- Configure Role Hierarchy and Sharing Rules
Build or update the Role Hierarchy to match the org's reporting structure. Add Sharing Rules to open up cross-team access per the requirements matrix: criteria-based for record-content sharing (all Opportunities in Region West to West sales engineers), ownership-based for role-based sharing (records owned by Sales Reps to Sales Operations). For each rule, choose the right target (Role, Role and Subordinates, Public Group, Queue). Save and let the sharing recalculation complete before testing.
- Test, audit, and document
Log in as test users from each user group and confirm they see exactly the records they should and no others. Audit edge cases: new hires, role changes, ownership transfers. Document the sharing design in the org's architecture wiki with a diagram of role hierarchy, a list of sharing rules per object, and the rationale for each design choice. Schedule a quarterly review with the business stakeholders to confirm the sharing still matches operational needs. Update the design as the business evolves.
- OWD changes trigger sharing recalculation for every record on the object. In large orgs, this can take hours and slow other operations.
- The Role Hierarchy must match the operating reporting structure. Misalignment causes records to roll up to the wrong managers and creates visibility complaints.
- Sharing is additive, not subtractive. There is no way to restrict access through a sharing rule; only to grant more access.
- Manual Sharing entries do not survive ownership transfers. Build into your runbook the steps to re-apply any manual shares after a transfer.
- Apex Managed Sharing requires careful design to avoid unintended access grants. Code review by a security-aware reviewer is essential.