App Permissions
Access to a published app has two independent axes. App Managers administer the app — they can edit it, publish it, and manage who else can use it. In-app roles govern what a person can do once they open the running app — the app's own code decides what each role can see and touch. A single person can hold one, the other, or both.
You manage both from the app detail page's Permissions tab (open the app's name from the home page, then Permissions). The same surface is also reachable directly at the app's permissions route, where it's titled "Manage app users."
The two axes
| Axis | Granted by | Controls |
|---|---|---|
| App Manager | An App Manager grant on the app, or a tenant-admin role | Whether someone can open the app in the builder, publish it, change its settings, and manage its members. |
| In-app role | A grant carrying a role from the app's catalog.yaml | What a user can do inside the running app. Enforced by the app's own code. |
A person who is an App Manager can manage the app but cannot necessarily open it — opening the deployed app requires an in-app role. That's why first publish offers to grant you a role (see below).
The App Managers tab
The App Managers tab lists everyone who can administer the app. App Managers can invite users, change roles, publish, and edit the app.
Tenant admins are always App Managers. Users with a tenant-admin role manage every app in the tenant automatically — you don't grant them here, and a banner on the tab says so. The App Managers tab lists only people granted explicitly.
You can't remove the only App Manager — promote someone else first. This prevents an app from being left with no one able to administer it.
The Users tab
The Users tab lists everyone with a role to use the app, and the role each holds. The set of available roles is defined in the app's catalog.yaml and shown read-only in the Roles panel beside the tables.
Roles are the app developer's concern: the platform stores the catalog and puts each user's role into their identity token (as the app_role claim), but the app's code decides what each role is allowed to do. To change the available roles, edit the roles block in catalog.yaml and republish — the role list re-syncs on every publish.
The starter template ships with a single user role. Add more roles (for example admin, approver, viewer) only when your app's code actually behaves differently for them.
A person can appear in both tabs — an App Manager who also holds an in-app role shows in both, cross-badged.
Inviting people
Open the App Managers or Users tab and select the add button. In the invite dialog:
- Search for a teammate by name or email. Only existing tenant members can be invited; if someone isn't in your tenant yet, ask your tenant admin to add them first.
- On the Users tab, pick the in-app role they should hold. On the App Managers tab, the role picker appears only if you also choose to grant them a role to use the app.
- Optionally use the cross-grant checkbox: on the Users tab, Also make this user an App Manager; on the App Managers tab, Also grant this App Manager a role to use the app. Both default off.
- Add them to the app.
Removing a grant is tab-aware: removing someone from one tab drops only that grant. If it was their only grant, the membership is deleted entirely; if they still hold the other axis, that grant is preserved.
Before first publish
The Permissions tab only works once an app has been published. Before the first publish there are no roles to assign and no one to manage, so the tab shows an "App is not published yet" message. On first publish you become the app's first App Manager, and the role catalog from catalog.yaml is synced so you can start inviting.
Grant yourself a role on first publish. Because being an App Manager doesn't by itself let you open the app, the first time you publish the builder shows a panel ("Add yourself to use this app") to add yourself with an in-app role — the same roles your invitees pick from. Skip it and you can grant yourself a role later from the Permissions tab.
Who can see an app at all
A non-manager with an in-app role can see the app and open it with View live, but the management surfaces — Settings, Configuration, Metrics, Database, and Permissions — are App-Manager-only. A user who has neither manage rights nor a role won't see the app in their catalog.
What's next
- Deploying and Versioning — publish and manage the deployment your members will use.
- The App Editor — where App Managers build the app.