3,000 m
The architecture
Start from data ownership
A single Salesforce org serving many business units is really a negotiation about who can see what. The sharing model is where that negotiation gets written down. Start with organisation-wide defaults set to private for anything sensitive, then open access deliberately. Going the other way, public by default and locked down later, never finishes, because nobody can prove what they would break.
Model ownership around business units rather than people. A record belongs to a unit, units map to public groups, and sharing rules grant access between groups. Roles still exist, but they handle management visibility, not cross-unit access. When a unit is added or merged, you change group membership rather than the shape of the model, which is a much shorter conversation.
300 m
The delivery team
Test access like it matters
Sharing is the part of the org most likely to be right in the design and wrong in production. Write tests that run as real users from each business unit and assert what they can and cannot see. System.runAs with a representative user per unit catches more problems than any number of review meetings, and it catches them before a customer does.
Access you have not tested is access you are guessing at.
Watch the performance side too. Large group memberships, deep role hierarchies and ownership skew all make sharing recalculation slow, and slow recalculation turns a routine data load into a weekend outage. Keep any single owner under ten thousand records, prefer fewer and larger groups, and schedule big ownership changes with the platform team rather than discovering them.
