Auditing a Multi-Subsidiary Salesforce Setup for Hidden Data Leaks

Not every multi-subsidiary setup needs hard data separation. The real triggers are: different pricing that shouldn't be visible across entities, a data residency or privacy requirement tied to a specific jurisdiction, or a subsidiary with its own P&L where leadership doesn't want other entities seeing its pipeline. Map which of these actually applies to your structure before designing sharing rules, since building strict separation where none is legally or competitively required just adds friction to cross-entity collaboration that might otherwise be useful.

Write down, for each subsidiary, which specific trigger applies and which doesn't, rather than defaulting every entity to the strictest possible separation just to be safe.

Run this check against your current org:

• Are pricing and discount fields visible to users outside the subsidiary that set them
• Do shared reports or dashboards roll up data across entities that shouldn't be combined for a leadership audience that only has visibility into one
• Can a user in one subsidiary see or edit records owned by another through a role hierarchy that was built before the subsidiary structure existed
• Are integration connections (a marketing tool, a billing system) scoped per subsidiary, or does one connection pull data across all of them by default

Any yes on the first three is worth investigating immediately, not scheduling for a future cleanup project.

Most multi-subsidiary needs can be solved with Salesforce's own sharing rules and role hierarchy, scoped by a subsidiary field on each record, without the cost and complexity of separate orgs. Separate orgs make sense only when subsidiaries have almost nothing in common operationally (different products, different sales processes, different compliance regimes) and even shared reporting infrastructure isn't worth the coordination cost. Most companies reach for separate orgs well before that threshold, and regret the lost visibility later.

Record types add a middle option worth knowing about: they let different subsidiaries use different page layouts and picklist values on the same object without splitting the underlying data, which covers a surprising share of what people initially assume needs a full org split.

After setting up sharing rules, test them as a user, not as an admin. Log in as a representative user from each subsidiary and confirm they genuinely can't see what they shouldn't, rather than trusting the rule configuration alone. Admin-level testing misses the exact permission-set combinations and role hierarchy quirks that actually cause leaks in practice.

Every new subsidiary added to the org should go through the same mapping exercise, not inherit whatever sharing rules happened to exist for the entity it's most similar to. A rule that made sense for the first two subsidiaries can quietly become wrong for a third with different requirements, and nobody notices until a leak surfaces months later.

Keep a short, dated record of when each subsidiary's sharing rules were last reviewed. A rule with no review date attached is one nobody can confirm is still correct, which is functionally the same as not having reviewed it at all.