Field-level security in Dataverse

Beyond row-level security from security roles, Dataverse supports field-level security (FLS) — restricting access to specific columns within a row. Some users can see and edit a row but cannot see sensitive columns like Salary, SSN, Credit Score, Internal Notes. FLS is the platform's answer for selective column-level access.

Profile-based. Field-level security operates through field security profiles — named groupings of users and teams who get specific access to specific protected fields:

1. Mark a field as Field-Level Secured. Each column has a "Secured" property; enabling it marks the column as FLS-protected.
2. Create a field security profile. A profile lists which secured fields it covers and what access (Read, Update, Create) is granted.
3. Assign users and teams to the profile. Only profile members get the specified access.

By default, when a field is marked secured, no one can access it except System Administrators and members of profiles that explicitly grant access.

Common use cases.

• HR data — Salary, Performance Rating, Disciplinary Notes on the Worker / Employee table. Visible to HR profile; hidden from line managers.
• Customer Financial Data — Credit Score, Internal Risk Assessment, Lifetime Value on the Account table. Visible to credit / finance profiles; hidden from regular sales.
• PII / Sensitive Personal Data — SSN, Date of Birth, Bank Account on the Contact table. Visible to compliance / payroll; hidden from everyone else.
• Internal Comments — sensitive internal-only notes on customer-facing records. Visible to certain roles; hidden from the customer-facing team.

How the platform enforces.

• Form rendering — secured fields render blank (or as "********") for users without access.
• API responses — secured fields are stripped from API responses to unauthorised users.
• Reports and views — secured fields don't appear in lists, search, or exports for unauthorised users.
• Audit log — changes to secured fields can be tracked, but the audit log itself can be restricted to admins.

Profile composition. A user can be in multiple profiles; access is additive. A user in both "HR Read" and "HR Update" profiles for the Salary field can read and update; another user in only "HR Read" can read but not update.

Profile-specific data masks. Modern profile configurations support data masking — partial visibility:

• Show only the last 4 digits of an SSN to support agents.
• Show only the year of birth to marketing.
• Show only the bank's country code, not the full IBAN.

Masking is configured per profile; sophisticated rendering control.

Plugin and integration access. Server-side code accessing secured fields:

• Plug-ins running as a specific user — respect that user's field-level security. To bypass, the plug-in runs as System or a service user with full access.
• Power Automate flows — respect the flow owner's permissions, including FLS.
• Custom integrations — respect the authenticated user's permissions.

The pattern: integration service principals typically get full access; per-user contexts respect FLS.

Mobile and the offline cache. The offline cache in mobile Power Apps respects FLS:

• Secured fields not visible to the user are not cached.
• The local SQLite database stores only what the user can access.

Important for compliance — secured data not stored on the user's device.

FLS vs row-level vs business-unit security.

• Field-level — restricts which columns a user sees within a record they have row access to.
• Row-level (security role + scope) — restricts which records the user sees at all.
• Business unit / hierarchy — coarse scoping by organisational position.

All three layer together. A user sees rows their security role allows, with their assigned columns within those rows, restricted further by business unit / hierarchy.

Performance. FLS adds processing overhead to every query — the platform must check each user's profile membership and strip restricted fields from responses. For tables with many secured fields and complex profile structures, performance can degrade. Audit on busy tables.

Limits.

• Number of secured fields per table is bounded — Microsoft has limits (typically dozens, not thousands).
• Some field types have specific FLS behaviour — file fields, image fields may behave differently.
• Calculated columns that depend on secured fields are also restricted automatically.
• Audit logging of secured field changes may require explicit configuration.

Common pitfalls.

• Over-restriction — users can't perform their job because FLS hides fields they need. Iterate based on user feedback.
• Profile sprawl — many overlapping profiles become hard to administer. Consolidate.
• No FLS where it should be — sensitive data exposed to broad audiences. Audit periodically.
• FLS not in offline cache configuration — offline apps still expose secured data. Verify.

Operational reality. Use FLS for genuinely sensitive columns. Don't reach for it for general access control — that's what security roles are for. The layered model is the right approach.