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)
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.
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.
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.
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.
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.