Application permissions

The Application Permissions page (route /application-permissions-admin) assigns role-based permissions to users or groups, per web application.

Purpose

Web applications define roles (for example read-only, operator, or administrator). This page is the matrix that decides who may do what inside each application: each row is an identity (a user or group), and each column is a web application with a dropdown of that application’s roles. Assigning a role to an identity for an application grants that identity the role’s permissions in the application.

Why use it

Grant the right role inside each web application, rather than all-or-nothing access.
Assign the same identity roles in several applications from one screen.
Review at a glance who has which role in which application.
Use groups as identities so roles apply to whole teams (see Policies and permissions).

When to use it

When you expose a web application that defines roles (see Resources: applications).
When a user or group needs a different level of access per application.
During onboarding or role changes, to align application access with job duties.

Prerequisite: permission to administer permissions (an owner or administrator role).

How to use it

Open Access > Application Permissions from the left navigation.
Review the matrix. Each row shows the identity and one role dropdown per application.

Adding a permission

Select ADD PERMISSION. A new row appears with an identity field.

Start typing in the identity field. The autocomplete lists users, groups, and service accounts; select the one you want.
In the application columns, open the role dropdown for an application to see the available roles.

Select a role. The permission is saved automatically; the row now shows the assigned role.

To change or remove a role, open the dropdown again and pick a different role or the empty option. Use DELETE PERMISSIONS on ticked rows to remove the identity and its application roles.

Fields and controls reference

Control	Purpose	Required	Default	Valid values	Notes
Identity	The user, group, or service account being granted roles	Yes	n/a	Any identity in the organisation	Autocomplete with users, groups, and service accounts
Application columns	One per web application with roles	No	No role	The application’s roles, or empty	The dropdown only lists applications that define roles
ADD PERMISSION	Adds a new editable row	n/a	n/a	n/a
DELETE PERMISSIONS	Removes the selected rows and their roles	n/a	n/a	n/a	Bulk action on ticked rows

Dialogs and popups

Confirmation dialogs: deleting permissions confirms before acting. Role changes apply immediately without a separate confirmation.

Configuration versus diagnostics versus confirmation

Configuration: role assignments per identity per application. Changes are written as soon as a role is selected.
Diagnostics: the matrix itself is the record of configuration; there are no separate diagnostics on this screen.
Confirmation: deleting a permission row removes all the identity’s application roles. Role changes take effect asynchronously as the identity-aware proxy picks them up.

Pagination and async behaviour

The table pages at 25 rows per page.
Role assignments save asynchronously. After assigning or removing a role, wait a few seconds and reload to confirm. Application access for the identity changes shortly after.

Troubleshooting

An application column is missing: only applications that define roles appear as columns. Define roles on the application first (see Resources: applications).
An identity does not appear in the autocomplete: identities that already have roles may be filtered out. Check the existing rows first.
A role change has no effect: wait for the asynchronous update and confirm the correct identity row was edited.