Sharing rules: their power, and their risk
The role hierarchy opens access upward. Sharing rules open it sideways. When the people who need a set of records are not above the owners in the hierarchy (a regional team, a product specialist group, a partner channel), sharing rules are how you grant the access. They are essential, and they are also the layer most prone to quietly growing past the point anyone can explain.
How sharing rules grant access
A sharing rule says: records that meet this condition should be visible to this group. The condition is either ownership-based (records owned by a role, a queue, or a public group) or criteria-based (records where a field has a certain value). The recipients are a group, role, or role-and-subordinates. When a record matches, everyone in the recipient set gains the access level the rule specifies, Read Only or Read/Write, regardless of who owns the record.
That is genuinely powerful. One rule can correctly open a whole region’s pipeline to the team that supports it, with no manual sharing and no hierarchy gymnastics.
Why they accumulate
Sharing rules are easy to add and almost never removed. Each one solves a real, immediate problem, so it gets created. The problem passes, the team reorganizes, the field values change, but the rule stays. Multiply that by every “can you give this group access to those records?” request over several years, and you arrive at the common end state: dozens of rules, several overlapping, a few granting access for reasons that no longer apply, and no single person who can describe the whole set.
Criteria-based rules add a second subtlety. Because they grant based on a field value, a routine data change can move a record into or out of a rule’s scope. Access shifts without anyone touching the rule, which is great when it is intended and unsettling when it is not.
The questions worth asking
A healthy review of sharing rules is less about the rules one at a time and more about the result they produce together:
- For a given record, which sharing rules grant access to it, and to whom?
- Which groups receive access from rules whose original reason has expired?
- Where do multiple rules overlap so that access is wider than any single rule suggests?
These are hard to answer by reading the rule list, because the rule list shows intent, not outcome. The outcome is the union of every rule applied to your actual records and your actual group memberships.
Seeing the outcome, not just the rules
This is where it helps to look at access from the record’s point of view. When Who Sees What shows who can see a record, it names the specific sharing rule responsible whenever a rule is what granted access, and it resolves the group membership behind it so “this group has access” becomes “these people have access.” You can start from a record and see every rule touching it, or start from a group and see what your rules have actually opened to it. The rules stop being an undifferentiated list and become something you can reason about.
Sharing rules are not a problem to be avoided. They are the right tool for opening access across your org. The discipline is to treat them as a living set, review them by the access they produce rather than the intent they were created with, and keep a way to see, for any record, exactly which rule is doing the work.