Column-level security to control access
Record-level permissions are granted at the table level, but you may have certain columns associated with a table that contain data that is more sensitive than the other columns. For these situations, you use column-level security to control access to specific columns.
The scope of column-level security is organization-wide and applies to all data access requests, including the following requests and calls:
- Data access requests from within a client application, such as web browser, mobile client, or Microsoft Dynamics 365 for Outlook
- Web service calls using the Microsoft Dataverse web services (for use in plug-ins, custom workflow activities, and custom code)
- Reporting (using filtered views)
Note
The use of table-related terminology depends on the protocol or class library used. Learn more in Terminology use depending on protocol or technology.
Overview of column-level security
Column-level security is available for the default columns on most out-of-box tables, custom columns, and custom columns on custom tables. Column-level security is managed by the security profiles. To implement column-level security, a system administrator performs the following tasks.
Turn on column security on one or more columns for a given table.
Select an optional masking rule.
Associate one more existing security profiles, or create one or more new security profiles to grant the appropriate access to specific users or teams.
A security profile determines the following:
- Permissions to the secure columns
- Users and teams assigned access
A security profile can be configured to grant user or team members the following permissions at the column level:
- Read: Read-only access to the column's data.
- Read unmasked: The Read column's data unmasked values.
- Create: Users or teams in this profile can add data to this column when creating a row.
- Update: Users or teams in this profile can update the column's data after it has been created.
A combination of these four permissions can be configured to determine the user privileges for a specific data column.
Important
Unless one or more security profiles are assigned to a column with security, only users with the system administrator security role can access the column.
Example of restricting the mobile phone column for the Contact table
Imagine your company's policy is that sales members should have different levels of access to contact mobile phone numbers, as described here.
| User or Team | Access |
|---|---|
| Sales managers | Read-only. Can only view mobile phone numbers in masked form for contacts. |
| Vice presidents | Full. Can create, update, and view mobile phone numbers for contacts. |
| Salespersons and all other users | None. Can't create, update, or view mobile phone numbers for contacts. |
To restrict this column, you would do the following tasks.
Secure the column
Sign in to Power Apps.
Select Tables.
Select the Contact table.
Under Schema, select Columns.
Scroll down in the Columns list and open Mobile Phone.
Expand Advanced options, and then under General, select Enable column security.
Select the Masking rule dropdown menu, and select a masking rule.
Select Save.
Configure the security profiles
From the Power Platform admin center, select the environment to configure security profiles for.
Select Settings > Users + permissions > Column security profiles.
Select New Profile, enter a name, such as Sales Manager, enter a description, and then select Save.
Select Sales Manager, select the Users tab, select + Add Users, select the users that you want to grant access to the mobile phone number on the contact form, and then select Add.
Tip
Instead of adding each user, create one or more teams that include all users that you want to grant access.
Repeat the above steps and create a column security profile for Vice President.
Configure column permissions
Select the Column Security Profiles tab, and then select Sales Manager.
Select the Column Permission tab, select mobilephone, and then select Edit. Set the Read setting to Allowed, leave the others as Not Allowed, and then select Save.
Select the Column Security Profiles tab, and then select Vice President.
Select the Column Permissions tab, select mobilephone, and then select Edit. Set the Read setting to Allowed, the Read unmasked to One record, and the rest as Allowed, and then select Save.
Any users not defined in the previously created column security profiles won't have access to the mobile phone column on contact forms or views. The column value displays 
********, indicating that the column is secured.
Which columns can be secured?
Add a new column
Sign in to Power Apps.
Select Tables in the navigation pane.
Select a table, and then under Schema, select Columns.
Select the + New column option in the command bar.
Enter a Display name and Description.
Select a Data type.
The Lookup and Formula data types can't be set with column security. For more information, see Attributes that can't be enabled for column security.
Expand Advance options, and then under General, select the Enable column security checkbox.
View column-level security
Every column in the system contains a setting for whether column security is allowed. Use the following steps to view column security settings.
Sign in to Power Apps.
Select Tables in the navigation pane.
Select a table, and then under Schema, select Columns.
Select a column, expand Advanced options, and then under General, view the status of Enable column security.
If Enable column security can be selected, the column can be enabled for column security.
Attributes that can't be enabled for column security
Although most attributes can be secured, there are system attributes, such as IDs, timestamps, and record tracking attributes, that can't. Below are a few examples of attributes that can't be enabled for column security.
- ownerid, processid, stageid, accountid, contactid, businessunitid, organizationid, solutionid, supportingsolutionid, transactioncurrencyid, goalownerid, subscriptionid, userpuid, yammeruserid
- createdby, modifiedby, OwningTeam, OwningUser, Owningbusinessunit, yammeremailaddress
- createdon, EntityImage_Timestamp, modifiedon, OnHoldTime, overriddencreatedon, overwritetime, modifiedonbehalfby, timezoneruleversionnumber, versionnumber, importsequencenumber
- statecode, statuscode, componentstate, exchangerate, utcconversiontimezonecode
- fullname, firstname, middlename, lastname, yominame, yomifirstname, yomifullname, yomilastname, yomimiddlename
- deprecated columns, for example: traversedpath, stageid
You can view the table metadata for your organization including which columns can be enabled for column security, by installing the Metadata Browser solution described in Browse the Metadata for Your Organization.
Best practices when you use column security
When you use calculated column that include a column that is secured, data may be displayed in the calculated column to users that don't have permission to the secured column. In this situation, both the original column and the calculated column should be secured.
Some data, such as addresses, are made up of multiple columns. Therefore, to completely secure data that includes multiple columns, such as addresses, you must secure and configure the appropriate column security profiles on multiple columns for the table. For example, to completely secure addresses for a table, secure all relevant address columns, such as address_line1, address_line2, address_line3, address1_city, address1_composite, and so on.
Note
Changes to column security require a browser refresh from the end user on the client (like a model-driven app) for the changes to take effect. This should be considered when dynamically adjusting access rules.
Related information
Set up security permissions for a column
Enable or disable security for a column to control access
Add teams or users to a column security profile to control access
Hierarchy security