[object Object]

Field Security Profiles (FSP) restrict read, create, and update on individual columns. They are the right answer for SSN, credit limit, and salary. They are the wrong answer for hiding business logic. Most environments confuse the two.

How FSP actually evaluates

Mark a column “secured.” Without an FSP granting access, no one (except System Administrator) can read it. Note that “no one” includes plugins running in user context. A plugin needs to either run as system or have its impersonating user added to a permissive FSP.

The export gotcha

Excel exports respect FSP. Power BI pulls via the Web API also respect FSP, which surprises analytics teams expecting full data access. Service principals used by Power BI need their own FSP membership.

Power Platform Admin Center -> Environment -> Settings
-> Users + permissions -> Field Security Profiles
-> Add the Power BI service account to the relevant profile

Audit log behavior

Reads of secured columns are logged when read auditing is enabled. This is the only column type with native read auditing, which is why FSP is often used not to block access but to log who looked at PII. If that is your goal, accept the storage hit on the auditbase table; it grows fast.

FSP cannot mask, only block

Many teams want “show last 4 of SSN to junior reps, full SSN to senior reps.” FSP cannot do this. The column is either fully accessible or fully blocked. To mask, use a calculated column showing the masked value, secure the underlying column, and grant FSP access only to the senior role.

FSP and imports

Bulk imports via Data Import Wizard or ImportData API will silently skip secured columns the importing user cannot write. The error log shows zero errors and zero values written for that column. Check the import results carefully and grant the importing user FSP write access during the import window.

Performance impact

FSP adds an extra security check per column per row. On a view returning 5,000 rows with three secured columns, expect 100-200ms additional latency. Worth it for compliance. Not worth it for fields you secured “just in case.”

The decision rule

  • Genuinely sensitive PII or financial data -> FSP.
  • Hiding fields users should never see -> Form-level visibility, not FSP.
  • Hiding business logic -> Move it to a separate table with relationship-level security.
  • Audit who reads PII -> FSP plus read auditing.

What to do this week

List every secured column in your environment via Settings -> Security -> Field Security Profiles. For each, ask: is this column data sensitive enough to justify the latency and import friction? Unsecure the ones that are not.

[object Object]
Share