Read the permission catalogue
Permissions identify operations such as viewing a register or updating a role. The Permissions register is a discovery screen for tenant administrators, not a place to invent new backend powers.
Register columns
| Column | Meaning |
|---|---|
| ID | Internal permission identifier used by assignments |
| Code | Stable operation code, for example role.view |
| Name | Human-readable permission label |
| Created At / Created By | Catalogue audit information where available |
Search by an exact code when resolving access. Check pagination and clear the filter before concluding a permission is missing. A failed load has a Retry action; an empty filtered result is different from a failed request.
Discover a permission
- Open Authorization → Permissions.
- Search for the module/task code supplied by the relevant guide.
- Confirm both Code and Name.
- Open Assign permissions to review whether it can be selected for the target role.
- If unavailable, capture the code and displayed reason for the authorised owner/operator.
The current tenant register has no create/edit/delete actions. Global permission catalogue maintenance and approval of delegation eligibility are controlled release/operator activities. A new catalogue row alone would not implement a new application feature.
Held, grantable and assignable are different
| Term | Meaning |
|---|---|
| Held permission | The actor currently has this authority |
tenantGrantable | Operator-approved eligibility for bounded delegation by an actor with tenant.permission.grant |
| Assignable now | The server allows this actor to add it to this target in the current context |
| Existing grant | Already part of the target's set; preservation rules can differ from adding it anew |
An ordinary administrator may delegate an ordinary permission they already hold even if tenantGrantable is false. The eligibility flag does not grant the actor permission to execute the operation and is not the complete authorization decision. The assignment dialog's availability reasons and backend result are authoritative.
Example: Sara can delegate an approved receipt permission she does not hold, using bounded delegation and the required role-update authority. This does not let her post customer receipts personally. Ali, without bounded delegation, cannot add a missing permission to himself by editing his own role.
Reserved admin.*, platform.*, tenant.permission.grant and permission-catalogue write powers cannot be newly delegated through tenant administration.