What is Field-Level Security in Dynamics 365 CE?

Field-Level Security in Dynamics 365 Customer Engagement (Dynamics 365 CE) provides granular control over access to sensitive columns in Dataverse.

Standard Dataverse security roles primarily control access to tables and records. However, some organizations need to protect specific pieces of information within a record—for example, salary information, personal identification data, confidential pricing, credit limits, or sensitive customer information.

Field-level security, also referred to in current Microsoft documentation as column-level security, allows administrators to control whether specific users or teams can read, create, or update secured columns.

Why Is Field-Level Security Important?

Consider a Customer record containing:

• Customer Name
• Email
• Phone
• Credit Limit
• Internal Risk Rating
• Confidential Discount
• Account Manager

A sales representative might need access to the customer record but shouldn't necessarily be able to see the internal risk rating or confidential discount.

Record-level security alone cannot solve this requirement because the user may legitimately need access to the record.

Field-level security provides another security layer:

User → Security Role → Record Access → Column-Level Security

How Does Field-Level Security Work?

The basic implementation involves:

1. Enable column-level security on the required column.
2. Create or use a column security profile.
3. Associate users or teams with the profile.
4. Configure permissions for the secured column.

Microsoft provides permissions such as:

• Read
• Read Unmasked
• Create
• Update

Depending on configuration, sensitive values can also be masked rather than completely exposed.

Example

Imagine an organization has a custom column:

Customer → Credit Limit

Security could be configured as:

This allows the organization to implement a much more granular security model.

Field-Level Security vs Security Roles

These mechanisms solve different problems.

Security Roles

Control what users can do with records and tables.

Field-Level Security

Controls access to specific columns.

For example:

A user may have Read access to the Account table but still be prevented from viewing a secured Credit Limit column.

Dataverse security is cumulative across roles, teams, business units, record sharing, and other mechanisms, so field-level security should be designed as part of the broader Dataverse security architecture rather than in isolation.

Important Limitations and Considerations

Not every Dataverse column can necessarily be secured. Microsoft documents restrictions for certain column types, including lookup, formula, virtual-table, primary-name, and some system columns.

Architects should also consider calculated or composite columns. A secured source column can potentially contribute to another column's value, so related columns may need to be secured as well.

Best practice: Use field-level security for genuinely sensitive information, maintain the principle of least privilege, and test security using representative non-administrator accounts. System administrators aren't subject to the same column-security restrictions, so testing only with administrator accounts can produce misleading results.