Every layer above the baseline only adds access
A Salesforce sharing model survives growth only if somebody decided how the layers fit together before the first sharing rule went in. Most orgs assemble those layers one ticket at a time over five years, and end up with a model that performs badly and cannot be explained to an auditor. Five mechanisms decide who sees a record, and they stack in one direction.
Organisation-wide defaults set the baseline for each object. The role hierarchy opens access upward, so somebody above the owner in the tree can see what that owner holds. Sharing rules grant access sideways, driven either by record criteria or by the owner's role or group. Teams and manual sharing cover the exceptions that the general rules should not be bent to fit.
The property people misread is that the model only adds. Nothing above the baseline takes access away. A sharing rule cannot narrow what the role hierarchy already granted, and a second rule cannot cancel the first. Access accumulates from every layer, at the most generous level any of them allows. The honest answer to why somebody can see a record is often four separate reasons, and only one was deliberate.
Set the baseline as tight as the business will tolerate
Because everything above the baseline grants, the baseline decides how much of the model you control. Set each object's organisation-wide default to the most restrictive position the business can live with, then hand out access through layers you can read and remove. A private baseline gives you a design. A public read write baseline leaves nobody able to say who is meant to see anything.
Starting permissive feels helpful in month one. Nobody is blocked, no access tickets arrive, and the project ships on time. Tightening later is close to irreversible, because by then reports, list views, dashboards and daily habits all depend on access nobody granted on purpose. Changing an organisation-wide default becomes a political exercise with a stakeholder list and a change board, and the configuration edit itself is the trivial part.
When the business will not commit, make them describe the loss. Write down who stops seeing records under a private default and what they would do instead. Genuine cases usually resolve into one sharing rule or one report folder. The rest were relying on access nobody ever asked for, which is what an audit of who holds what turns up.
The role hierarchy should follow the access rollup
The role hierarchy exists so that access rolls up. If a record's owner sits below you in the tree, you can see the record. That is the whole mechanism, and it is why building the hierarchy from the organisation chart guarantees churn. Reporting lines change every time a director is hired, a region splits or two divisions merge, and each change arrives as a hierarchy edit with recalculation behind it.
Model the rollup the business needs instead. Ask who has to see other people's records for a defensible reason, such as the regional manager who approves discounts. Build roles for those rollups, keep the tree shallow, and leave job titles to permission sets and public groups, where a change costs nothing. Ownership gets easier once you have settled what it means for a record to sit in a queue.
A hierarchy nobody can draw on one page is usually a symptom of a larger decision that was never taken. If separate businesses are being held apart by role depth alone, the real argument is the one about running everything in a single org.
Sharing is calculated and stored, so it costs something
Salesforce does not work out access from first principles on every query. Sharing is calculated and stored, and stored results have to be maintained. Change a record's owner and the platform recomputes who can see it. Change the role hierarchy, a group's membership or a sharing rule, and it recomputes for everything the change touches. A permissive, deeply nested model with many rules therefore creates real work on every edit.
The symptoms rarely present as a security problem. They present as saves that take several seconds, an ownership reassignment screen that gives up, and recalculations that run long enough for somebody to ask whether the org is down. Confirm the current limits and recalculation behaviour in the documentation and then measure them in your own org, because the thresholds move between releases and depend on your own data volumes.
Mass ownership change is the case to plan for. Reassigning a book of accounts moves a large number of records at once, and the recalculation that follows can affect everybody working in the org, not only the teams named in the change. Territory realignment, a sales reorganisation and a big data load belong in an announced window, rather than at two on a Tuesday afternoon while the team is quoting. Rehearse the timings in a sandbox plan built around the seasonal releases first.
Manual shares outlive the reason they were granted
Manual sharing is the layer that accumulates. Somebody needs one record for one reason, an owner or an admin grants it in four seconds, and the reason expires long before the grant does. Cover for a two week absence. A complaint escalated to a director three years ago. Almost none of it is ever reviewed, and nothing lists everything a leaver can still open.
Public groups are what keep the rest of the model readable. A sharing rule written against a group states the business reason for the access, and the group's membership can change through a reorganisation without anybody reopening the rule. Rules written straight against roles have to be rewritten every time the tree moves, and they get rewritten in a hurry by whoever is covering that week.
Name groups after the access they carry rather than the team that happens to need it today. A group called enterprise deal reviewers survives three reorganisations. A group called northern region team leads does not, and neither do the eleven rules pointing at it.
Apex sharing stays rare, and testing means signing in
Programmatic sharing exists for the rule that genuinely cannot be expressed in configuration, and it should stay rare. Every Apex share is a grant no admin will find in setup. Document what each one does, which records it reaches, and what happens to existing grants when the rule changes. Code that hands out record access with no comment explaining why is the worst surprise in a security review.
Test by signing in, never by reading the configuration. Keep a handful of test users matching your most constrained job roles, refresh their setup whenever the model changes, and open the real list views, reports and record pages before sign off. A sharing rule tells you what somebody intended. A session tells you what the platform concluded after every layer had its say.
Run the same check on integration users and service accounts, which usually hold wider access than any human in the org and have nobody to answer to at review time. If your people and your automation move between orgs, then how identity lines up across Salesforce orgs decides who inherits that access next.
The check to run in an org you inherited
List every object whose organisation-wide default is public, and ask the business owner of each one to name the group of people who should not see those records. If they can name a group in under a minute, you have found a baseline that was set for convenience and a sharing model doing no work at all on that object. That list is short and cheap to produce.
Then count the manual shares. Pull the manual share rows on your three busiest objects, group them by the person they were granted to, and read the top ten. At least one of those people changed job over a year ago. Take that list to your next architecture review with the recalculation timings beside it, and the sharing model stops being a configuration detail and becomes funded work.
