Security roles in Dataverse are deceptively simple to author and devastating to misconfigure. Every long-lived environment we audit has at least one of the following problems, and any of them will fail an enterprise security review.
Anti-pattern 1: Cloning System Administrator
Someone needed “almost admin” access, so an admin cloned System Administrator, removed two privileges, and called it a day. The clone now grants prvCreateSystemForm, prvImportCustomization, and full plugin registration. That is a production-write key disguised as a job role.
Fix: build roles upward from Basic User plus delta privileges. Never clone down from admin.
Anti-pattern 2: Organization-level read on PII tables
A developer needed to test a view, granted Read = Organization on Contact, and forgot to revert it. Now every internal user can $select=emailaddress1,birthdate from the Web API. The audit log will not flag this because the access is “authorized.”
Fix: keep Contact, Lead, and any custom PII table at User or Business Unit read by default. Use sharing or team ownership for the genuine cross-BU exceptions.
Anti-pattern 3: Append vs Append To confusion
These two privileges read backwards from intuition. Append means “this record can be appended to another.” Append To means “another record can be appended to this one.” Reverse them and your activities silently fail to attach to accounts, or worse, attach to records the user should not see.
Anti-pattern 4: Privilege creep through team membership
Owner teams stack privileges by union. A user in three teams gets the most permissive setting across all three. Six months in, no one knows why a sales rep can delete opportunities. Run this monthly:
Power Platform Admin Center -> Environment -> Users + permissions
-> Security roles -> filter by user -> review effective privilegesAnti-pattern 5: Field-level security as access control
Field Security Profiles are for masking sensitive columns, not for hiding business logic. If you are using FLS to hide the creditlimit field from junior reps but the column still appears in views and exports as ********, you have telegraphed that the data exists. Use a separate table with a 1:N relationship instead.
What to do this week
Export your security role matrix with the Microsoft.Xrm.Tools.PrivilegeReport script, diff against last quarter, and flag every privilege escalation that lacks a ticket reference. That diff is your audit evidence.
