3.4 Column-Level Security & Hierarchy Security Models
Key Takeaways
- Column-Level Security (Field-Level Security) restricts Read, Create, and Update permissions on specific sensitive attributes, overriding table-level record access.
- System Administrators automatically hold full Read, Create, and Update permissions on all secured columns through the default System Administrator Column Security Profile.
- Column Security Profiles define the exact permission triad (Read: Yes/No, Create: Yes/No, Update: Yes/No) and can be assigned to individual Users or Microsoft Entra / Owner Teams.
- Hierarchy Security extends record visibility up the management chain using either the Manager Hierarchy model (direct reporting chain) or Position Hierarchy model (organizational position tree).
- Under Hierarchy Security, managers receive Read, Update, Append, and Append To access to direct reports' records at Depth 1, but only Read-Only access to indirect reports at Depth 2 and deeper (up to the configured maximum depth limit).
3.4 Column-Level Security & Hierarchy Security Models
While Business Units and Security Roles establish coarse-grained authorization at the table and record tiers, enterprise applications frequently require more granular controls. Organizations must protect highly sensitive individual fields (such as Social Security Numbers, executive compensation, or credit card details) and provide automated management oversight across reporting structures.
Microsoft Dataverse addresses these enterprise requirements through Column-Level Security (Field-Level Security) and Hierarchy Security Models.
1. Column-Level Security (Secured Fields)
Column-Level Security allows system customizers to restrict access to specific columns within a table without altering record-level security roles. Even if a user has full Organization-wide Write access to a Contact record, Column-Level Security can prevent that user from viewing or editing the Contact's Tax Identification Number or Credit Score.
+-----------------------------------------------------------------------------------+
| COLUMN-LEVEL SECURITY ARCHITECTURE |
| |
| +---------------------------------------------------------------------------+ |
| | CONTACT TABLE (User has Global Read/Write Security Role) | |
| | | |
| | - First Name: 'Alice' [Standard Column -> Visible & Editable]|
| | - Last Name: 'Smith' [Standard Column -> Visible & Editable]|
| | - Email: 'alice@contoso.com' [Standard Column -> Visible & Editable]|
| | | |
| | - SSN: '***-**-****' [SECURED COLUMN] | |
| | * User lacking Read Profile sees masked asterisks! | |
| | * User lacking Update Profile sees locked field on form! | |
| | * API queries return null/masked values! | |
| +---------------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------------+
Enabling Column Security
- Column Definition Property: In the Power Apps Maker Portal or Solution Explorer, open the target column properties and enable the "Enable Column Security" checkbox (
IsSecured = true). - Supported & Unsupported Columns:
- Supported: Most standard and custom columns (Single line of text, Multiple lines of text, Whole Number, Decimal, Currency, Date/Time, Lookup, Choice).
- Unsupported: Primary Key columns (
entityid), State/Status columns (statecode,statuscode), and system tracking timestamps (createdon,modifiedon).
2. Column Security Profiles & The Permission Triad
Once a column is secured, Dataverse blocks all non-administrative access by default until the column is explicitly configured within a Column Security Profile.
+-----------------------------------------------------------------------------------+
| COLUMN SECURITY PROFILE PERMISSION TRIAD |
| |
| +-------------------+ +-------------------+ +-------------------+ |
| | READ PERMISSION | | CREATE PERMISSION | | UPDATE PERMISSION | |
| | (Yes / No) | | (Yes / No) | | (Yes / No) | |
| | Controls viewing | | Controls initial | | Controls modifying|
| | data in forms, | | population when | | value on existing |
| | views, and API. | | creating record. | | saved record. |
| +-------------------+ +-------------------+ +-------------------+ |
+-----------------------------------------------------------------------------------+
Profile Configuration Mechanics
- Default System Administrator Profile: Every Dataverse environment includes a built-in System Administrator Profile that automatically grants full Read, Create, and Update permissions on every secured column. This ensures administrators are never locked out of system data.
- Custom Profiles: Administrators create custom Column Security Profiles (e.g., "HR Compensation Profile" or "Finance Payroll Profile").
- Granular Permission Combinations:
- Read Only (Read: Yes, Create: No, Update: No): Users can inspect the sensitive value but cannot enter or edit it.
- Create Only / Blind Entry (Read: No, Create: Yes, Update: No): Useful for call center agents who collect credit card numbers during onboarding but must never view or edit them afterward.
- Read/Update (Read: Yes, Create: Yes, Update: Update): Full operational maintenance.
- Assignment to Users and Teams: Column Security Profiles can be assigned to individual users, traditional Owner Teams, or Microsoft Entra ID Group Teams.
Runtime & API Behavior
- UI Rendering: In model-driven forms, secured columns display a small key icon. If a user lacks Read permission, the field displays masked characters (e.g.,
********). If the user lacks Update permission, the field appears read-only. - API / Power Automate / Search: If an unauthorized user or automated cloud flow queries a secured column via the Web API, Dataverse returns
nullfor that attribute without failing the overall query.
3. Hierarchy Security Models: Manager vs. Position Hierarchy
In many organizations, managers require oversight of records owned by or shared with their subordinates without requiring broad Business Unit security roles or cumbersome sharing rules. Hierarchy Security extends record authorization based on organizational reporting structures.
+-----------------------------------------------------------------------------------+
| HIERARCHY SECURITY: MANAGER VS POSITION |
| |
| MANAGER HIERARCHY MODEL POSITION HIERARCHY MODEL |
| (Based on SystemUser 'Manager' Field) (Based on Position Hierarchy Table|
| |
| [VP of Sales] [Sales Director Position] |
| | | |
| v (Depth 1: Read/Write/Append) v (Depth 1) |
| [Sales Manager] [Sales Manager Position] |
| | | |
| v (Depth 2: READ-ONLY!) v (Depth 2) |
| [Sales Rep A] [Sales Rep Position] |
+-----------------------------------------------------------------------------------+
Manager Hierarchy Model
- Mechanism: Uses the standard
managerlookup field on the SystemUser table (systemuser.parentsystemuserid). - Topology: Strictly follows the management reporting chain defined in Dataverse or synchronized from Microsoft Entra ID.
- Limitation: A user can only have exactly one direct manager. Matrix reporting structures across different departments cannot be modeled via Manager Hierarchy.
Position Hierarchy Model
- Mechanism: Administrators define job positions (e.g., "Senior Account Executive", "Regional Sales Lead") using the Position table, link positions in a parent-child hierarchy, and assign users to positions.
- Flexibility: Allows defining reporting structures that span across different Business Units without modifying the user's direct line manager in Active Directory.
4. Hierarchy Depth Rules & Privilege Evaluation
When Hierarchy Security is enabled in Power Platform Admin Center, administrators must configure the Hierarchy Depth parameter (integer value representing levels of hierarchy traversal).
+-----------------------------------------------------------------------------------+
| HIERARCHY ACCESS RULES BY DEPTH LEVEL |
| |
| Manager (Root) |
| | |
| +---> DEPTH 1: Direct Report |
| | Access Granted: READ, WRITE, APPEND, APPEND TO |
| | (Manager can edit direct report's records!) |
| | |
| +---> DEPTH 2 to N: Indirect Report (Subordinate's Subordinate) |
| Access Granted: READ-ONLY |
| (Manager can view, but CANNOT edit indirect report's records!) |
+-----------------------------------------------------------------------------------+
Hierarchy Access Rules Table
| Subordinate Level | Traversal Depth | Permissions Granted to Manager | Prohibited Operations |
|---|---|---|---|
| Direct Report | Depth = 1 | Read, Write, Append, Append To | Delete, Assign, Share |
| Indirect Report | Depth ≥ 2 (up to max configured depth) | Read-Only | Write, Delete, Assign, Share, Append, Append To |
| Beyond Configured Depth | Depth > Max Configured Depth | None (No hierarchy access) | All operations |
[!WARNING] Hierarchy Security does not grant Delete, Assign, or Share privileges at any depth level. To delete or assign a subordinate's record, the manager must hold sufficient table-level security role privileges or have the record explicitly shared with them.
Performance & Governance Best Practices
- Table Inclusions: Configure Hierarchy Security for "Selected Tables" rather than "All Tables" to avoid unnecessary query overhead on high-volume background transaction tables.
- Depth Limits: Keep Hierarchy Depth to 3 or 4 levels. Deep hierarchical trees (e.g., depth ≥ 6) require complex recursive SQL joins during view rendering, impacting user interface responsiveness.
A healthcare provider requires that all clinical staff members have permission to view and edit Patient records, but only members of the Compliance Team can view the patient's Social Security Number (SSN) column. Other staff members must see masked asterisks in the SSN field. How should the functional consultant configure this requirement?
An organization configures Manager Hierarchy Security with a Hierarchy Depth of 3 on the Opportunity table. User 1 is the direct manager of User 2, and User 2 is the direct manager of User 3. User 3 creates and owns a new Opportunity record. What access does User 1 have to User 3's Opportunity record through Hierarchy Security?
A call center onboarding team needs to enter new customer credit card numbers into a secured column when registering accounts. However, compliance regulations mandate that onboarding agents must never be able to view previously saved credit card numbers or edit them after record creation. How should the Column Security Profile for the onboarding agents be configured?
Which of the following operations is NEVER granted to a manager on a direct report's records through Hierarchy Security, even at Depth 1?