Organization-Wide Defaults establish the most restrictive baseline access level for every record of an object, and every other sharing mechanism — Role Hierarchy, Sharing Rules, and Manual Sharing — can only ever ADD additional access on top of that baseline, never remove or restrict access below it. This means OWD functions as a genuine floor: if OWD is set to Public Read/Write, no Sharing Rule or hierarchy configuration can make a specific record more restricted than that for any user, since restriction is structurally not something these widening mechanisms are capable of doing. This is why OWD is considered the single most consequential access decision in an org — getting it wrong cannot be fully corrected by clever configuration of the other three mechanisms alone.

This requires a Criteria-Based Sharing Rule, not an Owner-Based one, because the requirement is driven entirely by a field value on the record, Priority equals Critical, with complete indifference to who actually owns the Case. An Owner-Based Sharing Rule can only grant access based on WHO owns a record, such as sharing everything owned by a specific Role with another group — it has no mechanism to evaluate field values at all, so it structurally cannot express a requirement like this one. A Criteria-Based Sharing Rule is purpose-built for exactly this scenario, evaluating the record's own field values independent of ownership, and granting the defined audience access to any record matching that criteria regardless of who currently owns it.

Manual Sharing is the most granular mechanism because it operates on exactly one record shared with exactly one user or group at a time, with no rule engine, criteria evaluation, or ongoing automation involved — it is a direct, one-off grant rather than a reusable pattern. Manual Sharing is the right tool specifically when an access need is genuinely a one-time exception rather than a recurring pattern — for example, one Opportunity that needs a single collaborator from a completely unrelated team for a specific, limited reason. Building a permanent, org-wide Sharing Rule for a need that will only ever apply to one record and one person is unnecessary overhead and adds a rule that must be maintained indefinitely; Manual Sharing solves the narrow case cleanly without that ongoing maintenance burden.

Targeting a Public Group adds a layer of indirection between the Sharing Rule's logic and its actual membership, which makes future changes significantly easier to manage. If a Sharing Rule targets a Role directly and the business later needs to add a contractor, a cross-functional teammate, or someone whose position does not map cleanly onto that exact Role, the Sharing Rule itself would need to be edited or duplicated. By contrast, if the rule targets a Public Group, an Admin can simply add or remove members from that group whenever membership needs change, without ever touching the underlying Sharing Rule configuration at all. This makes Public Groups the more maintainable, professional default target for Sharing Rules, even in cases where the audience currently happens to map cleanly to a single Role.

The definitive, fastest diagnostic step is to open the specific Opportunity record and click the Sharing button, which displays the complete, explicit list of every user or group with access to that record and the exact REASON for each grant — labeled clearly as Owner, a specific Role in the hierarchy, a named Sharing Rule, or Manual Share. Rather than reasoning through OWD, Role Hierarchy, Sharing Rules, and Manual Sharing theoretically from scratch, the Sharing button gives Salesforce's own definitive answer directly from the platform, removing any guesswork. Once the reason is identified, whether it is an overly broad Sharing Rule, an unintended Role Hierarchy position, or a stale Manual Share, that specific mechanism can be corrected directly, since the diagnostic step points precisely at the actual cause rather than requiring investigation across all four mechanisms individually.

The evaluation starts with Profile Object-Level Security: if the user's Profile does not grant at least Read on the object, access is denied immediately and nothing else is evaluated. If Object-Level access exists, the baseline for record-level visibility is the Organization-Wide Default, which is then potentially widened by three additional mechanisms, evaluated together rather than in a strict further sequence: first, Ownership combined with Role Hierarchy, meaning the user owns the record or is positioned above the owner in the hierarchy with Grant Access Using Hierarchies enabled; second, Sharing Rules, either Owner-Based or Criteria-Based, which grant access to a defined audience typically represented as a Public Group; and third, Manual Sharing, which grants access to one specific user or group for that one specific record. The user's final access to that record is the WIDEST access granted by any of these three widening mechanisms on top of the OWD baseline — if none of them grant access, the user cannot see the record, and the Sharing button on the record itself will show exactly which of these mechanisms, if any, is responsible.