The Matrix Org and the Read-Only Director
Northwind Components has 380 internal users plus 60 partner community users. Reps own Deal_Registration__c, whose org-wide default is Private. The company just moved to a matrix model: every rep reports to a regional manager inside the role hierarchy and to a product-line director who sits in a separate branch of the hierarchy, not above them. Regional Sales Ops (12 users) must edit every Deal Registration in their own region but see nothing in other regions. Legal (5 users) needs read-only access to every Deal Registration globally. Partners must see only records they own. Two complaints landed this week: a product-line director can open her reps' Deal Registrations but gets 'insufficient privileges' when she edits one, and a partner user reports seeing a competitor's record in the community.
1. The product-line director can open her reps' Deal Registrations but cannot edit them. Diagnose the likely cause and describe how you would confirm it before changing any configuration.
Read the worked answer
Record-level access in Salesforce is the minimum of two things: the object-level permission on the user's profile/permission sets, and the sharing access granted by OWD, role hierarchy, sharing rules, teams, or manual shares. 'Can see, can't edit' almost always means the ceiling was set by one of those layers.
Order of investigation:
- Object permission first. Open her permission set assignments and check Deal_Registration__c for Read vs. Edit. If she has Read only, no sharing rule will ever grant edit - this is the cheapest thing to rule out and the most common cause when a new role is built from a read-only template.
- Then the sharing path. Use the Sharing button on the record (admin-visible) to see the full list of users with access and why - role hierarchy, sharing rule, team, manual share. Because she is in a different hierarchy branch, she is not inheriting edit from the hierarchy; she is almost certainly getting access from a criteria-based sharing rule defined as Read Only.
- Check whether her access is even rule-based. If the Sharing button shows no rule, her access may come from a manual share or a queue/team membership.
Fix at the layer that is actually limiting - promote the sharing rule to Read/Write, or if the intent is 'directors may see everything but edit only their own line', leave the rule and grant edit through a named permission set scoped to her team. Don't reach for View All/Modify All Data; it breaks the region restriction for everyone holding it.
2. A partner user reports seeing a Deal Registration owned by another partner. How would you trace the source of that access, and what would you change?
Read the worked answer
Partner/community users still obey the org's sharing model, but they gain access through a different set of doors, so trace in this order:
- Reproduce as the user. Log in as the partner user, open the record, and use the Sharing button to see the access path. That single screen usually answers it in seconds.
- Sharing set. In the community/experience settings, check the sharing set mapped to that partner account. A sharing set grants access where a field on the record matches a field on the user's account - a loose or null-valued match field (for example, matching on a blank Region__c) will leak records across partners.
- Sharing rules and groups. Confirm no criteria-based rule or public group used for internal sharing also contains partner users or 'All Customer Community Users'.
- Role hierarchy. Partner users are placed under the channel manager in the role hierarchy. If the partner's role or the record owner's role sits in a branch that implies visibility, the partner inherits it.
Likely fix: keep the record OWD Private, correct the sharing set match field so it is populated and unique per partner, and if necessary move from sharing sets to guest/partner sharing rules based on a partner ID field you control. Then re-test as a second partner account to prove the leak is closed, and check whether the same bad match field exposed other records - that is the real risk, not the one record reported.
3. How do you give the 12 Regional Sales Ops users edit access to every Deal Registration in their own region, given that they all occupy one shared role and the org is matrixed?
Read the worked answer
The role hierarchy cannot express this. A single shared role either sits above all regions (too much access) or below none (too little), and moving the ops users into each region's branch would break the matrix reporting they were hired into. So the answer is record sharing plus object permission, not hierarchy surgery.
Recommended design:
- Keep OWD on Deal_Registration__c Private, so nothing is granted implicitly.
- Create one public group per region (Ops - North, Ops - South, …) and place the relevant ops users in each. Users can belong to more than one group if they cover two regions.
- Create one criteria-based sharing rule per region on Region__c, sharing with the matching group at Read/Write. Criteria-based rules can reference a custom field like Region__c; they cannot reference owner-based fields, which is why region must be a real field on the record.
- Grant the object-level Edit permission through a permission set on top of their existing read-only profile, so the sharing rule is not fighting a Read-only ceiling.
Judgement notes: sharing rules only ever extend access - they never restrict - so the region boundary must come from OWD plus criteria, never from a rule that excludes. Watch the per-object sharing rule limit as the region count grows, and expect recalculation to be asynchronous after you change criteria or group membership; if a large data load is running, defer sharing recalculation so the rule does not thrash during the load.