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. See 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.
Enable column security on one or more columns for a given table.
Associate one more existing security profile, 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.
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 three 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 security enabled column, only users with the system administrator security role will have access to the column.
Example for 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 for contacts. |
Vice presidents | Full. Can create, update, and view mobile phone numbers for contacts. |
Salespersons and all other users | None. Cannot 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 Dataverse > 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, enable Enable column security.
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 all three settings to 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?
Adding 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 cannot be enabled for column security.
Expand Advance options, and then under General, select the Enable column security checkbox.
Viewing 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.
See also
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
Feedback
https://aka.ms/ContentUserFeedback.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see:Submit and view feedback for