Permissions
Part of No-code app permissions
Separating viewer, editor and administrator access
Define what viewers, editors and administrators may do in a no-code app, then match those duties to app and data-source permissions.
Separate these roles by what people need to do. A viewer reads permitted records. An editor changes specified records or fields. An administrator maintains the app and its access settings. These labels are a starting point: actual grants depend on the builder, data source and the person's other permissions.
Write actions into a role matrix
In a maintenance app, someone reporting a fault might read the request they submitted, while a coordinator updates its assignment. Neither needs to alter the app's sharing settings.
| Action | Viewer | Editor | Administrator |
|---|---|---|---|
| Read an authorised request | Allow | Allow | Allow if needed for support |
| Create a request | Decide separately | Decide separately | No automatic need |
| Change assignment or status | Deny | Allow for specified records | No automatic need |
| Delete or export records | Decide separately | Decide separately | Decide separately |
| Change app rules or invite users | Deny | Deny | Allow for named maintainers |
This is an example policy, not a vendor's built-in role definition. A person can hold several grants, so assess their combined access. Decide separately who may delete, export, share and approve.
Match the duties to the product
Power Apps canvas sharing distinguishes a User, who can run an app, from a Co-Owner, who can run, edit and share it but cannot delete it or change its owners. That distinction concerns the app.
Users of a Dataverse-backed app also need suitable data roles for its tables. Permission to run a canvas app does not, by itself, make someone a read-only data user.
For Airtable, identify the access a person needs for the interface and the underlying app, then check the product's current permission settings before assigning viewer, editor or maintainer duties.
For AppSheet, map the actions people need to the controls available in the app and its connected data source. Check that each person's access supports their work without granting unnecessary maintenance duties.
The products do not share one role model. Translate the action matrix into the chosen product's grants, then check the result with ordinary accounts.
Keep maintenance access separate
Give editors only the record actions needed for their work. Keep changes to fields, filters, connections and sharing with named maintainers. If a maintainer needs sensitive record access for support, define that grant explicitly; maintenance duties alone do not settle which records they should read.
Review temporary cover and staff moves. An editor helping another team may need a grant with an end condition. A former maintainer may still have access through a workspace group after an app-level change. Check the combined grants.
Before rollout, use fictional permitted and denied records for each role. Try the actions that matter, including export and access changes where available, and inspect the saved result. Correct any mismatch in the configured app.
