Platform App Builder: Private Opportunities, a Matrix Team, and 60 Contractors

Private Opportunities, a Matrix Team, and 60 Contractors

Tidewater Insurance has 900 internal users and 60 contractors. Opportunity org-wide defaults are Private, and the role hierarchy mirrors 14 regions; each regional VP sees the opportunities of everyone below them. Three gaps need closing. A 40-person cross-region 'Major Accounts' team needs read access to every opportunity in three named regions, whatever role they sit in. One VP manages two regions but sits beneath only one of them in the hierarchy, so her team cannot see the second region's records at all. Contractors must be unable to export data and must not see opportunities above $1M, but must see smaller ones in their assigned region - and today they sit under the same regional VPs as employees. Every opportunity report sits in a folder shared with All Internal Users.

1. Choose the sharing mechanism for each of the three gaps and say why the obvious alternative fails.

Read the worked answer

A private OWD plus additive sharing is the right backbone. Nothing here should be solved by loosening the default.

Gap 1 - the Major Accounts team (record-criteria based).

Use a criteria-based sharing rule filtered on a Region__c field on Opportunity, shared with the public group Major Accounts, with Read Only access.
This only works because region is a field on the record. Criteria-based sharing rules cannot use owner fields (owner role, owner profile) as criteria - that is the trap. If region exists only as a role name, add the field.
The alternative, changing the OWD to Public Read Only, shares everything with 900 people and destroys gap 3 in the same stroke.

Gap 2 - the VP who owns two regions (owner-based).

Use an owner-based sharing rule: records owned by the role or public group for Region B are shared with the VP's role/public group. Criteria-based rules cannot express 'owned by', so they are the wrong tool here.
The hierarchy cannot be fixed laterally. You could re-parent the hierarchy, but that silently changes access for everyone under those branches - a sharing rule is reversible and auditable.

Gap 3 - contractors (this one is structural).

Sharing rules only grant; they never deny. While contractors sit beneath regional VPs they inherit access through the hierarchy, and no rule can take it back.
Move contractor roles to the top of the hierarchy with no subordinates, and give them a criteria-based rule: Region__c = 'assigned' AND Amount < 1000000.
Trim the profile: remove Export Reports, Data Export, and the 'View All Data' family; remove contractors from All Internal Users and from the report folder's sharing, and audit report and dashboard folders separately - folder access is not governed by record sharing.

2. How do you prove the model is correct before the next audit?

Read the worked answer

Test as the users, not as the admin.

Build a matrix of personas: a Major Accounts rep, the dual-region VP, a contractor in each region, and an employee in a region the contractor should not reach. For each, capture expected vs. actual on the same five opportunity records (one under $1M in region, one over $1M, one in another region, one owned by the VP's second region, one with no region).
Use the Sharing button and 'View a user's access' rather than 'log in as' alone; logging in as a user does not always surface folder and report access problems.
Check the org-wide default checkbox 'Grant Access Using Hierarchies' - it is easy to uncheck on one object during a pilot and forget.
Test the negative case explicitly: a contractor opening a $2M opportunity by direct URL must be refused. If they can see it, the role hierarchy change did not take effect or a manual share exists.
Recheck after every reorg. Role hierarchy changes are the single most common cause of silent over-sharing in an org this size; put a quarterly access review on the calendar and store the persona matrix with the release notes.