Every organization must protect its data while ensuring that the right people have access when they need it. Microsoft Power Platform offers a feature called hierarchy security, which makes controlling access easier and more precise, even in complex environments. In this guide, we'll walk you through the basics in plain language.
What Is Hierarchy Security?
Hierarchy security is an extension of existing security models in Power Platform (like business units, security roles, sharing, and teams). It helps you define who can see what data by building a logical structure based on a company's management or job roles. Essentially, it lets you assign access rights using a "chain of command" or a "position" setup. This method is not only more granular (or detailed) but also reduces the effort required to manage many business units manually.
The Two Key Models
There are two common ways to organize hierarchy security:
1. Manager Hierarchy
The manager hierarchy is based on a direct reporting structure. Here's what you need to know:
Direct Reporting: Each user record has a "Manager" field. If you are a manager, you can automatically see the records of your direct reports.
Access Levels: Typically, managers have full access (like Read, Write, or even Append privileges) to the records of their direct reports.
Business Unit Consideration: In many cases, a manager must belong either to the same business unit as their direct reports or to a parent business unit. This helps keep data within appropriate areas of the organization.
Example: Think of it like a classroom. A teacher (manager) can see the assignments and progress of every student in their class (direct reports), but not necessarily that of teachers in another class.
2. Position Hierarchy
The position hierarchy is a little different:
Job Roles Over Reporting: Rather than relying on who reports to whom, positions are defined by job titles or roles. If you have a "Manager" or "Director" role, for example, you can access the data of users assigned to lower roles, even if they are in separate business units.
Cross-Business Unit Access: This model is especially useful if your organization's structure is fluid, or if you need to share data across different verticals (like customer service cases) without being strictly tied to a direct management chain.
Example: Imagine a retail chain where a regional manager can access data from all store managers, no matter the location. Here, the "position" determines access, not direct reporting lines.
How to Set Up Hierarchy Security
Getting started with hierarchy security is straightforward if you have the right permissions:
Enable the Feature:
By default, hierarchy security is turned off. Administrators need to enable it in the Power Platform settings by navigating to:
Choose Your Model:
Depending on your organization's needs, select either:
Set the Depth:
The "depth" setting controls how many levels deep a manager or role can access data. For instance, setting the depth to 2 means a manager can see data for direct reports and one level further down the hierarchy.
Assign Proper Privileges:
Even after enabling hierarchy security, users (especially managers or higher positioned persons) must have at least a user-level Read privilege on the data (like on a Case or Account table) to see what's available to their reports or subordinate roles.
With these simple steps, administrators can ensure that access is adequately controlled while still allowing collaboration and efficient data management throughout the organization.
Why Hierarchy Security Matters
For beginners, understanding the "why" is as important as learning the "how." Here are some benefits:
Granular Access Control: Instead of exposing all data or needing many separate business units, you gain fine control over who sees what.
Reduced Maintenance: By leveraging the chain of command or positions, you avoid the administrative overhead of setting permissions manually for every user.
Flexibility: Whether you have a traditional management structure or a more fluid organization, hierarchy security adapts so the right people always have the right level of access.
Below is an expanded, beginner-friendly example that shows how hierarchy security works in Microsoft Power Platform. This example uses a real-life business scenario so you can easily see how data access is determined.
A Simple Company Structure Example
Imagine a company named TechWorld with the following management structure:
In this scenario, TechWorld uses hierarchy security to control who can see which data records (like customer accounts or sales opportunities).
Example Using the Manager Hierarchy
In the manager hierarchy model, access is based on the direct reporting relationship defined on each user's record (via a "Manager" field).
Direct Reporting:
Priya, the Sales Representative, reports directly to Rohan, the Sales Manager.
Rohan can directly see and manage all records created or assigned to Priya. He might have permissions to read, update, or even delete these records.
Up the Chain:
Rohan, the Sales Manager, in turn, reports to Neha, the VP of Sales.
Neha can view (or have read-only access, depending on the configuration) the records of her direct subordinate Rohan and even indirectly view Priya's data if the system's depth setting allows. For example, if the depth is set to 2, Neha would see the data of Rohan (level 1) and Priya (level 2).
At the Top:
Finally, Rahul, the CEO, sits at the top of this management chain. He might have access to the data of Neha and possibly limited, read-only access to the lower levels (depending on the depth limitation you set).
Here's a table that summarizes the data access:
| User | Direct Subordinates | Access Type |
|---|
| Rohan (Sales Manager) | Priya (Sales Representative) | Full access: Read, Write, Modify Priya's records. |
| Neha (VP of Sales) | Rohan (Sales Manager) | Directly: full access to Rohan's records; indirectly: read-only access to Priya's records (if depth ≥ 2). |
| Rahul (CEO) | Neha (VP of Sales) | May have full access to Neha's records; read-only to records of lower levels if configured via depth settings. |
In simple terms:
Direct managers see more (full privileges) for the people who report directly to them.
Managers higher up might see only summaries or read-only versions for employees further down the chain if the depth setting doesn't allow full access.
Example Using the Position Hierarchy
Now, consider the position hierarchy model. Instead of relying only on who reports to whom, this model grants access based on an employee's job role within a defined organizational structure.
Imagine TechWorld also sets up positions that rank across business units:
Position: CEO (Rahul)
Position: VP of Sales (Neha)
Position: Sales Manager (Rohan)
Position: Sales Representative (Priya)
Even if the reporting lines aren't direct or employees are in different locations, those at higher positions automatically get access to the data of employees in lower positions.
For example:
Rahul, as CEO, can view records of everyone in the sales chain.
Neha, as VP of Sales, gains access to records for Sales Managers and Sales Representatives under her position, even if those managers don't report directly to her in the system.
Rohan (Sales Manager) sees full details for the Sales Representatives in his chain.
This approach is especially helpful when your company is organized by job functions rather than a strict reporting line, or when data needs to be shared across different business units.
Comments
Post a Comment