Most Salesforce orgs start open and get locked down only after someone sees data they shouldn't. Sharing is easier to get right if you build it in layers, from the broadest default to the narrowest exception.
Start with organization-wide defaults
Organization-wide defaults (OWD) set the baseline for each object: Private, Public Read Only, or Public Read/Write. Private is the safest starting point for sensitive objects like cases or opportunities — you can always open access up later, but clawing it back after users have built reports and habits around open data is painful.
Set OWD deliberately, object by object. An object that holds customer financial details deserves Private; a reference object like a product catalog can stay Public Read Only without much risk.
The role hierarchy does the heavy lifting
The role hierarchy grants access upward: managers see what their reports see. This is usually the right shape for a sales org, where a regional manager legitimately needs their team's pipeline.
The trap is building a hierarchy that mirrors the org chart too literally. Every extra level is another path for data to flow upward, and roles created for reporting convenience can quietly widen access. Keep the hierarchy as flat as the business allows, and review it when teams reorganize.
Sharing rules fill the gaps
Sharing rules open access sideways — for example, giving the support team read access to accounts owned by sales, or letting a partner team see cases in their region. They are rule-based, so they stay consistent as records change, unlike one-off manual shares.
Keep sharing rules few and well-named. A dozen overlapping rules on one object is a sign the data model or the role design needs rethinking, not more rules.
Manual sharing is the exception, not the system
Manual sharing lets a record owner share a single record with a specific user or group. It is useful for genuine one-offs — a deal that needs a specialist's eyes for a week. It is a poor substitute for a rule: manual shares are invisible in most audits, they survive after the reason is gone, and nobody remembers to remove them.
If you find yourself manually sharing the same kind of record repeatedly, that is a sharing rule waiting to be written. The same discipline applies to automation: when access depends on who runs a process, understanding how flow run context works keeps you from accidentally granting a flow more access than its user should have.
A quick audit checklist
- OWD set to the most restrictive sensible default per object.
- Role hierarchy reviewed after every reorg.
- Sharing rules documented with their business reason.
- Manual shares reviewed quarterly and removed when stale.
- Field-level security checked alongside record access — a shared record with sensitive fields exposed is still a leak.
Sharing done well is invisible: users see exactly what they need, and nothing they don't. That is worth an hour of design before it becomes a cleanup project.
Originally published at Way2Force
Top comments (0)