Restrict Sensitive Fields in Dataverse with Column-Level Security

Not every user in an organization needs to see every value inside a record. A clinical support worker may need a patient’s name and diagnosis but should never see their insurance number. Dataverse column‑level security lets you selectively hide and protect individual fields while keeping the rest of the row visible. This article walks through a realistic healthcare scenario, from identifying the sensitive column to assigning access with a security profile.

Scenario: Protecting Patient Insurance Numbers

Imagine a clinic that manages patient records with a Dataverse table named Patients. The table contains the following columns:

• FullName (Text)
• DateOfBirth (Date Only)
• Diagnosis (Text)
• InsuranceNumber (Text) — the sensitive field

The goal is to allow only a small group of executive staff and billing officers to view the InsuranceNumber column. All other users who have access to the Patients table should see everything except that field.

Enable Security on the Sensitive Column

Column security must be turned on at the column level before any profile can control access.

1. In make.powerapps.com, open the table Patients.
2. Select the InsuranceNumber column and choose Edit.
3. Expand Advanced options and locate the Enable column security check box.
4. Mark the check box and save the column.

Once enabled, the InsuranceNumber field immediately becomes hidden for every user except those holding a system administrator role. Any view or form that contains this column will display it as empty or show a “Hidden” label.

Create a Column Security Profile

A column security profile defines which columns a user can read, update, or create. Think of it as a security role that applies only to columns.

1. Go to the Power Platform Admin Center and open your environment.
2. Navigate to Settings > Users + Permissions > Column security profiles.
3. Select New profile and give it a name, e.g., Clinic Executive Access.
4. Save the profile.

Configure Permissions on the Protected Column

After creating the profile, you must specify what actions are allowed for the InsuranceNumber column.

1. Open the Clinic Executive Access profile.

2. On the Column permissions tab, locate the InsuranceNumber row (only columns with column security enabled appear here).

3. Choose Edit and set the three permissions:

   • Read — Can the user see the field value?
   • Update — Can the user change the value on an existing record?
   • Create — Can the user fill in the field when adding a new record?

   For your executive staff, set each to Allowed. For other profiles, leave them as Not Allowed (the default).

4. Save your changes.

Assign the Profile to Users or Teams

Now you need to grant the profile to the people who should access the protected column.

Option A – Individual Users

1. Open the Clinic Executive Access profile.
2. Go to the Users tab and select Add users.
3. Pick the users (or administrative accounts) that require visibility.
4. Save the profile.

Option B – Security Teams (Recommended)

To reduce maintenance overhead, associate the profile with a security team. Team members automatically inherit column‑level permissions.

1. In the Power Platform Admin Center, under Teams, create a new Owner team named Clinic Executives.
2. Add the appropriate users to the team.
3. Assign any needed security roles to the team (e.g., Basic User) so they can read the Patients table.
4. Open the Clinic Executive Access column security profile, navigate to the Teams tab, and add the Clinic Executives team.

Any user belonging to that team now has read/write/create ability on the InsuranceNumber column.

Testing and Verification

• Log into the model‑driven app as a test user who is not assigned the profile. Open a Patients record. The InsuranceNumber field will appear blank or show “---”.
• Log in as a user who belongs to the Clinic Executives team. The same field will display the actual insurance number and allow editing.

Common Pitfalls to Avoid

• Missing table‑level permissions. Column security only controls the column; users still need a Dataverse security role that grants read access to the table itself. Without the role, they cannot see any columns at all.
• Field still appears in views. Removing a column from a view is a separate task. Enable column security and, if desired, adjust the view to hide the column from non‑authorized users.
• Propagation delays. Permission changes can take several minutes to apply across all services. Wait a few minutes before testing.
• Confusion with field‑level business rules. Column security is a permission boundary enforced by Dataverse. Business rules only control visibility on a form and do not protect data from direct API access.

Recommendations

Use column‑level security only for truly sensitive data — regulatory requirements (HIPAA, GDPR) are a good guide. For everyday fields, consider simpler approaches like form customizations or role‑based views. Layering column security with proper security roles and auditing provides a robust defense for your most critical information.

References

• Matthew Devaney’s original guide on column‑level security: How To Enable Column Level Security In Dataverse
• Microsoft Learn: Column‑level security in Dataverse — placeholder for official documentation
• Power Platform Admin Center guide — placeholder for environment settings