If a Power Pages form opens but a record cannot be saved, separate access to the page from permission to change the record. Web roles are not limited to interface visibility. This guide explains the standard authorization model and a practical troubleshooting sequence.
Updated October 2, 2026: this revision replaces the earlier UI-only description of web roles, direct Contact-to-security-role instructions and comparison table.
The standard authorization model
For an authenticated site user, the core relationship is Contact → Web Role → Table Permissions and Page Permissions. Keep this site configuration distinct from the security roles used by internal Dataverse users.
| Component | Purpose | What to review |
|---|---|---|
| Web role | Connects site users to permissions | Contact membership and authenticated/anonymous role settings |
| Table permission | Defines permitted record access and operations | Table, access type, relationships and privileges |
| Page permission | Restricts access to a page | Page and allowed web roles |
| Dataverse security role | Governs Dataverse access for users and teams | Internal application security; not a direct Contact assignment step in the standard site model |
See Microsoft’s documentation for web roles, table permissions and page permissions. Page access alone does not establish record-update permission.
Example: editing your own Contact record
For a custom Contact-editing form, verify the signed-in Contact and web role, then associate an appropriate Contact table permission with that role. Self access scopes permission to the user’s own Contact; select the operations needed, such as Read and Write. Check page access, form configuration and record selection separately. This is a design example, not a replacement procedure for the built-in profile feature.
Test with two different site users. Each should be able to edit the intended personal information without gaining access to the other user’s record.
When the form is visible but saving fails
- Identify the affected site user, page and operation. An administrator’s successful test is not sufficient.
- Check web-role membership and the associated table permission: scope, relationships and required operations.
- Check the form’s target record, required fields and validation.
- If access settings do not explain the failure, investigate server-side processing, including plug-ins and the actual error.
Treat this as a diagnostic sequence, not proof that every save failure is caused by one missing privilege.
Enhanced authorization is a separate preview
As of October 2, 2026, Microsoft documents enhanced authorization as a preview. When enabled, it maps site Contacts and web roles to Dataverse security constructs and moves permission evaluation into Dataverse. Do not interpret this as a requirement to manually assign security roles to Contacts on every existing site.
Check whether the feature is enabled, supported solution versions, plug-in execution context and column-security behavior before applying preview-specific guidance.
Document the intended access
Record who should perform each operation, from which page, on which records, and why. Use that record to define both successful-access tests and tests showing that another person’s data remains inaccessible.
コメント