PL-400: Matrix Reporting Across Regions and Service Lines

Matrix Reporting Across Regions and Service Lines

Contoso Services has 900 internal users organised as three regions by four service lines. Regional directors must read every opportunity in their own region regardless of service line. Service line leads must read every opportunity for their own line across all three regions. Forty commercial users may see a Margin column on Opportunity; nobody else may, including regional directors. Roughly thirty times a week a deal team of five to eight people needs temporary access to a specific opportunity for about thirty days. Separately, 200 external contractors will authenticate to a Power Pages site and must see only cases belonging to their own contact record.

1. Design the business unit, team, and role model that satisfies the directors, the line leads, and the ad hoc deal teams.

Read the worked answer

Business unit = region; owner teams = region + service line; access teams for the ad hoc cases.

Do not create twelve business units. BU-scoped roles cascade to child BUs, so a twelve-BU matrix produces either over-permission or a maze of record sharing that is impossible to audit.
With BU = region and an owner team per (region, line) owning the opportunities:
- A regional director sits in the region's BU with a role granting BU-level Read - that covers records owned by every team in that BU, across all four lines. Requirement met with zero sharing.
- A service line lead is added as a member of the three line owner teams (one per region) with a User-level role. Team membership grants the team's privileges over the team's records, so a line lead reads their line everywhere without seeing other lines. Note they leave the team when they change role - make that part of the joiner/mover process.
Deal teams: access teams, not sharing. An access team template on Opportunity lets the record owner add members for exactly the period, and access disappears when the record is closed or the membership is trimmed. Manual sharing at this frequency creates an unauditable share list nobody prunes after thirty days.

Verify: build two test users per persona and run a record-visibility matrix test in Test, including a line lead who also becomes a director.

2. How do you protect the Margin column, and what breaks when you do?

Read the worked answer

Use column security, but assume the feature has sharp edges.

Create a column security profile granting Read (and Update only if the 40 users must edit) on Margin, assign those users or a dedicated team, then enable column security on the column itself. Order matters: the column will refuse to be secured until at least one profile exists.
Who still sees it: system administrators and system customisers bypass column security by design. If the requirement is literally "nobody else", the forty users cannot be System Administrator in Prod - that is an access-model decision, not a configuration one.
What degrades: secured columns are unreliable in client-side filtering, sorting, and aggregation for restricted users, and cannot be used by business rules or calculated logic that runs as them. Views that filter or sort on Margin will misbehave for the other 860 users.
Cheaper alternative to check first: if the real requirement is "may see, may not edit", a field-level business rule or a role without write on the column is far less disruptive - confirm the intent before securing.

Verify: test as a non-privileged user in the model-driven app, in a view sorted by Margin, in an export to Excel, and through the Web API before signing off.

3. The 200 contractors must see only their own cases on the Power Pages site. What is the access design, and where do such designs usually leak?

Read the worked answer

Contact-scoped table permissions, not web-role-only security.

Create a web role for contractors and table permissions on Case with scope = Contact, relating Case to the signed-in contact through the customer field. Scope is what restricts rows; a web role on its own only decides which operations are possible, so a Global-scope permission would expose every case to every contractor while looking correctly configured.
If contractor cases belong to the contractor's parent account rather than the individual, use scope = Account and set the relationship to the contact's parent customer; choose one model deliberately, because mixing them produces "works for some users" bugs.
Grant permissions separately on the child tables the case view needs - notes and attachments are the usual gap where the page renders empty or throws.
Contractors must be authenticated contacts with an assigned web role; invitations or an identity provider rule assign the role, and an unassigned contact authenticates into an empty site.

Verify: test with two contractor contacts who each own a case, confirm each sees exactly one, then confirm an anonymous browser sees none. Check the audit log for any Global-scope permission that slipped in.