Dataverse Hierarchy Security - Manager & Position

Dataverse Hierarchy Security - Manager & Position

Clear steps, rules and a Position-hierarchy example-styled with Dataverse theme green.

Manager Hierarchy - Setup & Notes

When to use

Use Manager Hierarchy when you want access to flow from a user to their manager(s) based on the Manager field in Azure AD / Entra ID.

Important rule

The subordinate must be in the same Business Unit or a child Business Unit of the manager. If not, you will see: This user is not a member of the manager's business organization.

Quick checklist
  • Table must be User or Team-owned.
  • Record owner must be a User (not a Team).
  • Manager must be assigned in Azure AD (Manager property).

Step-by-step (Manager Hierarchy)

  1. Go to Settings > User Permissions > Hierarchy Security.
  2. Enable Manager Hierarchy and set the hierarchy depth.
  3. For the table: click Configure (include in Manager hierarchy) and assign a test manager to a user.
  4. Save & publish. Note: the subordinate must be in the same Business Unit (or a child BU) as the manager.
  5. Create a security role for the table and give basic user-level access to employees (Create/Read/Write as User-level for employees).
  6. Assign that security role to the employee users. Managers must have Read = Business Unit or Parent:Child BU so hierarchy can extend visibility.
Result

When an employee creates a record, the manager receives extended access (according to the configured depth) — full control only if manager's role grants it (hierarchy extends existing privileges).

Position Hierarchy — Setup & Example

When to use

Use Position Hierarchy when you want a flexible, org-chart-like access model that ignores Business Unit boundaries. Good for shared-services, matrix structures, or when employees are spread across BUs.

Important rules
  • Define Positions and the parent-child relationships between them.
  • Assign each user to a Position record.
  • Manager’s security role must still have at least Read = Business Unit (or Parent:Child BU / Organization) — Read = User is insufficient.

Position Hierarchy : Step-by-step

  1. Go to Settings > User Permissions > Hierarchy Security and enable Position Hierarchy.
  2. Create the Position records (e.g., CEO, Manager, Staff) and set parent relationships.
  3. Assign each user to a Position (user form > Position field).
  4. Include the target table in the Position hierarchy configuration (click Configure for the table).
  5. Create/assign security roles: employees get user-level Create/Read/Write; managers need Read = Business Unit or higher so hierarchy can extend access.

Simple example

Positions
  • CEO (top)
  • Regional Manager (parent = CEO)
  • Team Lead (parent = Regional Manager)
  • Developer (parent = Team Lead)

Assign users to these positions (User A = Developer, User B = Team Lead). If Developer creates a record, Team Lead and Regional Manager will see it via Position hierarchy regardless of their Business Units (as long as their security roles have the minimum Read level required).

Final tips

  • Always publish customizations after changing Hierarchy settings and roles.
  • Allow a short propagation time (a few minutes) after changes before retesting.
  • Test with real user accounts (not just admins) to validate effective permissions.

Manager Hierarchy vs Position Hierarchy - Comparison

When to use which?

Use this quick comparison to decide whether Manager or Position hierarchy suits your business structure.

Criteria Manager Hierarchy Position Hierarchy
Business Unit Restrictions ✔ Must be same BU or child BU ✔ No BU restriction (works across all BUs)
Assign Manager from Different BU? ❌ Not allowed — system blocks it ✔ Allowed
Source of Hierarchy Azure AD Manager Positions you configure manually
Use Case Simple linear org structure Cross-BU, matrix, shared-services teams
Minimum Read Level for Managers user BU or Parent:Child BU (User-level not enough)
Flexibility Medium - follows BU rules tightly High- you control the entire position map
Conclusion

Choose Manager Hierarchy if your org chart strictly follows Business Units. Choose Position Hierarchy if teams operate across Business Units or you want full control over hierarchy design.

Comments

Post a Comment

Popular posts from this blog

Part 1: Creating Code Apps in Power Apps - A step-by-step guide (with real errors I faced & how I fixed them)

Image
Intro In this post I’ll walk you through how I set up a code-based app for Power Apps (React/Vite front-end + Power Platform CLI for packaging/deployment), the exact errors I ran into, and how I solved them. If you want a hands-on, copy-paste able guide that covers Node versions, pac auth, environment issues, and packaging tips, this is for you. Prerequisites Microsoft 365 account with access to a Power Platform environment Node.js ( 20.19+  recommended LTS) VS Code Install power platform tools extension in VS Code. Steps: Step 1 : Open Visual Studio Code and launch the integrated terminal. Step 2: In the terminal, run the following commands one by one.   mkdir D:\CodeApps - Force cd D:\CodeApps npm create vite @latest myfirstapp -- -- template react - ts cd D:\CodeApps\myfirstapp npm install Initially, I ran the command: npm create vite@latest MyFirstApp -- --template react-ts This gave the error: Invalid package.json name The issue was caused because package...
Read more

Calling Microsoft Graph API from Power Automate Using Azure App Services – Step-by-Step Guide

Image
Step 1: You should have an Azure subscription, or if you have access to the Microsoft Entra Admin Center, you can create an app from there. This app can then be used in Power Automate to connect to Microsoft Graph API. Step 2: Click on "New registration" , provide a name for your app, assign the required API permissions (such as Microsoft Graph permissions), and then click "Register" to complete the app registration process. Step 3: After registration, you'll be redirected to the app's overview page. From there, navigate to the API permissions tab and click "Add a permission" to assign the necessary Microsoft Graph API permissions. Step 4: Select Microsoft Graph as the API, and based on your requirements, choose the appropriate permissions. In my case, I selected Application permissions , which do not require user sign-in and are suitable for background services or automation. Step 5: Select the required Microsoft Graph API permissions. Yo...
Read more

Step-by-Step Guide: Power Automate Custom Connector Using Graph API from Azure App Service

Image
Step 1: Open Power Automate, navigate to the Custom Connectors tab, and select Create from blank as shown in the image below. custom connector(click image for better resolution) Step 2: In the General tab, upload an icon (less than 1MB), add a description, select the correct scheme (in my case, HTTPS ), and provide the host name. For example, if your API URL is https://graph.microsoft.com/v1.0/users/{email} , the host name will be the highlighted part — graph.microsoft.com . Step 3: Go to the Security tab. Here, you need to select the authentication method. Choose OAuth 2.0 as the authentication type, as shown in the image below. Step 4: Select the Identity Provider as Azure Active Directory . Check the box Enable Service Principal Support . This option allows you to create a connection using a Client ID and Client Secret instead of using the user's own authentication. Next, provide the Client ID , Client Secret , Tenant ID , and other required details as shown in t...
Read more