Fabrikam Industrial - Matrix Security Across Lines and Regions

Choose one dimension to own data and one mechanism for cross-dimension visibility - trying to make business units represent both lines and regions is the classic failure here.

• Business units = product line. That matches who creates and owns the record. A record can only belong to one business unit, so regions cannot also be business units.
• Owner teams for deal teams. Create one team per deal and make it the owner of the opportunity. Team ownership gives all five members access and lets the record be reassigned between them, which an access team cannot do - access teams share records but never own them.
• Manager hierarchy for the VPs. Enable hierarchy security with the manager hierarchy and make the regional VP the manager of record for the sellers in that region. This grants read on records owned by users and teams beneath them without mass sharing. Validate the org chart first: a user has exactly one manager, so sellers who report to a product-line lead cannot also report to a VP.
• If the org chart cannot be modelled, the fallback is a custom position hierarchy table or region teams with a read-only security role plus sharing - both cost more maintenance.
• Service desk: an owner team that owns all cases, with a security role that excludes HR case types. Prefer restricting by record type or a business-unit boundary over relying on users to filter views.

Use column security profiles on the specific columns: set the columns as secured, create one profile granting Read (and Update only where required), and assign it to the 30 finance users or a finance team. Users with no profile see the column masked; keep the number of secured columns small because each one adds server-side checks on every retrieve.

State the limits explicitly to the business:

• System Administrators bypass column security. Anyone holding that role sees everything, so the control is not a compliance boundary against admins.
• Not every surface honours it. Reporting and data-export paths (for example Power BI over the TDS endpoint, and some bulk export patterns) are outside the column-security enforcement. If the data is regulated, mask it at the reporting layer too or exclude the column from the extract.
• Calculated and rollup columns cannot be secured the same way - do not derive a secured value into an unprotected calculated column.
• Several client behaviours degrade gracefully but visibly (blank or masked fields in views); set expectations with users before go-live.

Add auditing on the secured columns so read/update of margin and salary is traceable - separation of duties matters more than the masking alone.

External users authenticate as contacts in Dataverse and are authorised by web roles plus table permissions; they consume no Power Platform per-user licences, but they do need the site's authentication capacity and identity configuration.

• One web role per distributor type, granted the minimum pages.
• Table permission on Quote with scope Account (or Contact if quotes relate directly to the contact), granting Read only, tied to the contact's parent account so each distributor sees only its own quotes. Do not use Global scope - that is the most common data leak in portal implementations.
• Table permission on Quote Line with scope Parent, so lines inherit the parent quote's access rather than being independently permissive.
• Grant Append/Append To only if the business truly needs relationships to be created from the site; otherwise omit.
• Web page access control rules to hide any page that lists all quotes or exposes approval actions.

Verify with two test accounts in different distributors that a guessed URL to another quote's record returns nothing - table permissions apply at the Web API layer, so this test is meaningful. Finally, confirm that internal users of the site (if any) reach the same data through their licensed security roles and that the two models do not accidentally overlap.