Permissions & audience targeting

Who sees what, SharePoint list permissions vs Forms365 audience rules, and why both matter.

SharePoint Forms365 has two distinct permission layers. Knowing the difference keeps you from accidentally relying on the wrong one.

Layer 1, SharePoint list permissions

Live on the SharePoint list itself, governed by SP's permission model. They control:

Who can read items, the form can't display data the user has no permission to read
Who can write items, submit fails if the user lacks Contribute on the list
Per-column edit rights, SharePoint can mark individual columns read-only for specific groups

This is the real security boundary. Whatever your form does, the SharePoint list ultimately decides who can read/write what.

Layer 2, Audience trimming in the form

Live on each form component. They control what the form shows:

showForGroups / hideForGroups / enableForGroups / disableForGroups

This is UI affordance, not security. A user with write access to the list can write any column via the REST API regardless of what the form trimmed away.

The mental model

Use SharePoint list permissions when the data itself must not be visible/writable to certain users. This is the secure path.
Use audience trimming in the form when the data is genuinely visible/writable to everyone with form access, but you want to simplify the experience, hide irrelevant fields, disable approval buttons for non-managers, etc.

Common mistake: relying on audience trimming for security

Bad:

"I hide the salary field with hideForGroups: ["Non-HR"], so non-HR people can't see salaries."

Why it's wrong: the value is still rendered into the React tree and sent to the client. A user with developer tools can read it. Worse, the SP list still has the column readable by anyone with Contribute.

Good:

"I set the SP Salary column to be readable only by the HR group via SharePoint column permissions. The form's audience rule on the same field is then just for tidiness, non-HR users don't see an empty field with no value to read."

Designer audience tab

The Audience tab in the property panel writes the four group-based properties mentioned above. Behind the scenes, group references are stored as GUIDs (not display names) so they survive group renames.