In Part 1 we set up row-level and column-level security for a single user — Jordan. In Part 2 we created Business Units, Owner Teams, and demonstrated the BU boundary with Sam. Morgan and Jordan are both members of the HR Team, Sam is in Finance with Finance Self-Service, and everyone’s core access flows through team membership rather than individual assignment.
This post takes that foundation and layers on three things: Security Role scoping — the difference between the BU field on a role and the access level on each privilege — then hierarchical security so Morgan can see Jordan’s data as their manager, and finally the Parent:Child BU access level that extends Morgan’s visibility into a child Business Unit.
Where We Left Off
At the end of Part 2, the Contoso environment had:
| User | Business Unit | Team | Security Role | Column Profile | Can see Salary? |
|---|---|---|---|---|---|
| Alex | Root | — | System Administrator (direct) | Bypassed | ✓ Always |
| Jordan | Contoso - HR | HR Team | Employee Self-Service (via team) | HR Salary Access (via team) | ✓ Own row + team row |
| Morgan | Contoso - HR | HR Team | Employee Self-Service (via team) | HR Salary Access (via team) | ✓ Own row + team row |
| Sam | Contoso - Finance | — | Finance Self-Service (direct) | None | ✗ Blank |
Morgan and Jordan see the same things: their own rows and any HR-Team-owned rows. Sam is completely walled off in Finance. But Morgan is Jordan’s manager and should be able to review their reports’ data without needing Organisation-level Read. And when Contoso adds a trainee sub-group under HR, Morgan needs to see those records too.
This post introduces Riley, an HR trainee, specifically to demonstrate the Parent:Child BU access level.
The Security Role Business Unit Field vs the Privilege Access Level
Part 2’s “Three Things Named Business Unit” section introduced the taxonomy. This section puts it to a concrete test with a new role.
The two settings that share the words “Business Unit” but do completely different things:
| Setting | Where you find it | What it controls |
|---|---|---|
| Business Unit field on the Security Role record | Set when you create or edit the role (top of the role form) | A governance/filing label — which BU the role record is catalogued under. Does not restrict who can be assigned the role, and does not affect which records the role lets its holders see. |
| Access level on an individual privilege (e.g. Read → Business Unit) | Set per-table, per-privilege inside the role’s permission grid | How far that specific privilege reaches into the org chart. Evaluated against the assigned user’s own Business Unit at the moment access is checked — not against the role’s home BU field above. |
The concrete proof comes next: creating HR Manager Self-Service filed under Contoso - HR and watching what happens when you change the Read access level while the role’s BU field stays the same throughout.
Setting Up the Child BU and Riley
Before testing Morgan’s manager role, add the missing piece from Part 2’s BU hierarchy: a child Business Unit for HR trainees.
Go to the Admin Center → your environment → Settings → Users + permissions → Business units → + New.
Create the following Business Unit:
Contoso - HR Trainees(parent:Contoso - HR)
Add Riley
Riley needs to exist as a licensed user in the Microsoft 365 tenant. Once they do, Alex adds them in the Admin Center: Users + permissions → Users → + Add users → search for Riley → add.
After adding Riley, assign them to the right Business Unit: open Riley’s user record → Business Unit → change to Contoso - HR Trainees.
Assign the Basic User role to Riley via Manage security roles.
Create the HR Trainee Self-Service Role
Alex creates a HR Trainee Self-Service role: Security roles → + New role → Business Unit: Contoso - HR Trainees. On the Employee Salary table, set Create, Read, and Write all to User and leave the remaining privileges at None → Save. Assign it to Riley via Riley’s user record → Manage security roles.
Give Riley a salary row — log in as Riley (or have Alex create one owned by Riley). Riley can now create, see, and edit their own row.
Give Morgan Manager-Level Read — Starting With Plain Business Unit
Now create the role that gives Morgan visibility beyond her own row. This is also the live demonstration of how the role’s BU field and the privilege access level interact — or rather, how they don’t.
Create a HR Manager Self-Service role: Security roles → + New role:
| Field | Value | Note |
|---|---|---|
| Role Name | HR Manager Self-Service | |
| Business Unit | Contoso - HR | Governance label — does not control record visibility. |
| Description | Extends Read access for HR managers beyond their own records | |
| Applies To | Users and Teams | |
| Member’s privilege inheritance | Direct User (Basic) access level and Team privileges |
On the Employee Salary table, set Read to Business Unit and leave everything else at None. Morgan’s create and edit privileges already come from Employee Self-Service via HR Team; this role only extends her Read reach. Save.
Assign it to Morgan via Morgan’s user record → Manage security roles.
What Morgan Sees — and Why
Open the table as Morgan. With Read at plain Business Unit, Morgan now sees:
- Morgan’s own row
- Jordan’s row (also owned by a
Contoso - HRuser — the same Business Unit as Morgan) - The HR Team-owned row (team membership, unrelated to this new role)
Riley’s row is still missing. Riley is in Contoso - HR Trainees — a child of Contoso - HR — and plain Business Unit access level does not look down into children, only across users who share the exact same BU.
The role is filed under Contoso - HR and Read is set to Business Unit — both say “Business Unit” but they do different things. The Read privilege reaches Contoso - HR records because Morgan’s own Business Unit is Contoso - HR, not because of the role’s BU field. If Morgan moved to a different BU, the same role would give her visibility into that BU’s records instead.
The Parent:Child BU Access Level
There is one access level the series has not yet demonstrated: Parent:Child BU. You created Contoso - HR Trainees as a child of Contoso - HR and added Riley there for exactly this reason.
The scenario: Riley is a new HR trainee. Morgan, as the HR manager covering both the core team and the trainee sub-group, needs to see records from both BUs. The question is: which access level on Morgan’s role covers that?
| Access level | Covers |
|---|---|
| User | Only Morgan’s own records |
| Business Unit | Contoso - HR users (Jordan, Morgan) — not Riley |
| Parent:Child BU | Contoso - HR and all child BUs, including Contoso - HR Trainees (Riley) |
| Organisation | Every record in the environment — too broad |
Extending to Parent:Child BU
Go back to Security roles → open HR Manager Self-Service → change the Employee Salary Read access level from Business Unit to Parent:Child BU → Save.
Refresh the table as Morgan. Riley’s row now appears too:
- Morgan’s own row
- Jordan’s row (in
Contoso - HR, within the Parent:Child scope) - Riley’s row (in
Contoso - HR Trainees, a child BU — also within the Parent:Child scope) - The HR Team-owned row (team membership)
Nothing else about the role changed — only the depth that single access level reaches.
Open as Sam. Sam still sees only Sam’s own Finance row — Parent:Child BU never crosses into an unrelated branch of the hierarchy.
Hierarchical Security — Morgan Sees Jordan’s Row
So far, Morgan’s visibility into Jordan’s row comes from the HR Manager Self-Service role. Dataverse provides a second, independent mechanism: Hierarchical Security — access based on the reporting line rather than the BU tree.
To prove this access works independently, start by removing the role-based grant.
Remove the Role-Based Grant
Open HR Manager Self-Service → Employee Salary → change Read from Parent:Child BU to User → Save.
Refresh the table as Morgan. She now sees only:
- Morgan’s own row
- The HR Team-owned row
Jordan’s and Riley’s rows are gone. Any access to a report’s data from here on comes from Hierarchical Security alone.
Set the Manager Field
Users + permissions → Users → open Jordan’s user record → set Manager to Morgan → Save.
Enable Hierarchical Security
Settings → Users + permissions → Hierarchy security:
- Toggle Enable Hierarchy Modelling to On.
- Leave the model set to Manager Hierarchy.
- Set Depth to
1. - Save.
Sign Morgan out and back in.
Confirm Direct-Report Access
Refresh the table as Morgan. Jordan’s row reappears — no role grants it, so this is purely hierarchical.
Edit Jordan’s Salary value as Morgan. The edit succeeds. For a direct report, Hierarchical Security grants Read, Write, Append, and AppendTo.
Confirm Non-Direct-Report Access (Read Only)
Set Riley’s Manager to Jordan → Save. The reporting chain is now Riley → Jordan → Morgan.
At Depth 1, Riley is out of scope — only direct reports are covered. Increase Depth to 2 → Save. Sign Morgan out and back in.
Refresh as Morgan. Riley’s row now appears. Attempt to edit Riley’s Salary — the edit is rejected. For a non-direct report (reached only through Depth > 1), access is Read only.
Restore Configuration
- Disable Hierarchy security (toggle Enable Hierarchy Modelling to Off).
- Set Employee Salary Read on
HR Manager Self-Serviceback to Parent:Child BU.
Refresh as Morgan. Morgan’s own row, Jordan’s row, Riley’s row, and the team-owned row are all visible — now purely through the HR Manager Self-Service role’s Parent:Child BU Read.
Open as Jordan. Jordan sees only their own row and the team-owned row.
When would you leave hierarchy enabled? In production, Hierarchical Security is most valuable when a manager needs visibility that doesn’t map to a single BU scope, or when reports move between Business Units. This walkthrough disables it after the demonstration to keep the final state purely role-based, but the mechanism is available whenever the reporting line is the right access boundary.
Position Hierarchy — The Other Model
Dataverse offers a second hierarchy model: Position Hierarchy. It decouples access from the Manager field — instead, you create Position records, arrange them in a parent-child tree, and assign users to positions. Dataverse evaluates access against the Position tree, not the Manager field.
This is the better fit when:
- The hierarchy for security purposes doesn’t match the HR org chart
- A person has dotted-line reports who aren’t their direct reports but whose data they need to see
- You want to grant access based on role or function rather than reporting line
- The organisation has a matrix structure where a single Manager field can’t capture who should see what
You cannot run both models simultaneously. Since Manager Hierarchy was just disabled, this is a good point to see Position Hierarchy in action.
Create Positions
Settings → Users + permissions → Positions → + New.
Create three positions:
HR Manager(no parent)HR Analyst(parent:HR Manager)HR Trainee(parent:HR Manager)
Assign Morgan to HR Manager, Jordan to HR Analyst, and Riley to HR Trainee via each user’s record → Position field.
Remove the Role-Based Grant
Open HR Manager Self-Service → Employee Salary → change Read from Parent:Child BU to User → Save.
Refresh as Morgan. She sees only her own row and the team-owned row — Jordan’s and Riley’s rows are gone. This is the clean baseline.
Enable Position Hierarchy and Verify
Settings → Users + permissions → Hierarchy security:
- Toggle Enable Hierarchy Modelling to On.
- Set the model to Position Hierarchy.
- Set Depth to
1. - Save.
Sign Morgan out and back in. Refresh the table as Morgan — both Jordan’s and Riley’s rows reappear. No role grants them; the access comes from the Position tree (HR Manager → HR Analyst, HR Manager → HR Trainee).
Restore Configuration
- Disable Position Hierarchy (toggle Enable Hierarchy Modelling to Off).
- Set Employee Salary Read on
HR Manager Self-Serviceback to Parent:Child BU.
What the Access Structure Looks Like Now
| User | Business Unit | Team | Security Role source | Column Profile source | Can see Salary? |
|---|---|---|---|---|---|
| Alex | Root | — | System Administrator (direct) | Bypassed | ✓ Always |
| Jordan | Contoso - HR | HR Team | Employee Self-Service (via team) | HR Salary Access (via team) | ✓ Own row + team row |
| Morgan | Contoso - HR | HR Team | Employee Self-Service (via team) + HR Manager Self-Service (direct) | HR Salary Access (via team) | ✓ Own + Jordan + Riley + team row |
| Riley | Contoso - HR Trainees | — | HR Trainee Self-Service (direct) | None | ✓ Own row only |
| Sam | Contoso - Finance | — | Finance Self-Service (direct) | None | ✗ Blank |
Morgan’s HR Manager Self-Service role extends her Read access across the HR BU hierarchy via Parent:Child BU scope. Hierarchical Security was demonstrated and then disabled — it remains available if the reporting line becomes the preferred access boundary. Riley’s trainee BU is structurally subordinate to HR, and Morgan’s access reaches it without granting anything to Sam in Finance.
Things Worth Knowing
The privilege access level is per-privilege, not per-role. A single role can have Read at Parent:Child BU, Write at User, and Delete at None — each evaluates independently. The most permissive access level across all roles wins — Dataverse access is always additive.
Hierarchical security adds to Business Unit access — it does not replace it. When enabled, it covers records in the reporting line only. It does not grant access to arbitrary BU colleagues, and it does not cross into other BUs for users outside the reporting chain. This walkthrough disabled it after demonstrating it; re-enable it when the reporting line is the right access boundary for your organisation.
Parent:Child BU covers the parent BU and every child beneath it — not siblings. If you later add Contoso - HR London under Contoso - HR, Morgan’s Parent:Child BU Read covers it automatically. Finance data remains inaccessible regardless of depth.
Record sharing is the escape hatch for one-off exceptions. If Sam ever needs temporary visibility of one specific HR row, the record owner can share it — choosing exactly which privileges Sam gets on that record. Sharing does not change ownership and can be revoked at any time. Part 4 covers sharing in full alongside Access Teams.
The Finance Self-Service role is assigned directly to Sam for now. A Finance team following the same pattern as HR Team is the natural next step. That pattern, along with Entra ID Group Teams that make team membership automatic, is what Part 4 covers.