Troubleshooting "Access Denied" errors
This article helps you diagnose and fix "Access Denied" errors in MobilityManager. Almost every access problem comes down to a missing permission, the wrong tenant, or an inactive account — this guide walks through each in turn.
What "Access Denied" means
The platform checks permissions before it runs a protected action. If the signed-in user's roles in the current tenant do not include the permission the action requires, the request is refused with an "Access Denied" message. It is a permission decision, not a bug: the account simply lacks the right for that action in that context.
Step 1: Check the permission the action needs
Each protected feature requires a specific permission — for example approving a booking needs bookings:approve, and creating a user needs users:manage. Confirm which permission the action requires, then check whether the user holds it.
Tip: Review your own roles and permissions for the current tenant from your account. If the required permission is not listed, that is your answer, and the fix is a role change.
Step 2: Check the tenant
Roles and permissions are scoped per tenant. Permission checks are evaluated against the tenant of your current session, so a role you hold in one tenant grants nothing in another. If you have access "sometimes", you are likely switching between tenants.
- Confirm you are working in the tenant where you hold the role.
- If you need the same access in another tenant, an administrator must assign the role there too.
Step 3: Check the account is active and unlocked
A deactivated account cannot sign in at all. If sign-in itself fails, the account may have been deactivated, or it may be locked after repeated failed sign-in attempts. An administrator can reactivate the account, and an administrator password reset both sets a new password and clears the lockout.
Step 4: Check role-specific guardrails
Some denials are by design even when a user seems otherwise privileged:
| Symptom | Reason |
|---|---|
| Cannot grant or remove SystemAdmin | Only an existing SystemAdmin may assign or remove the SystemAdmin role. |
| Cannot edit or deactivate a particular user | Non-SystemAdmins can never act on a SystemAdmin account, and can only manage users in a tenant where they hold users:manage. |
| FleetManager cannot create users | FleetManager holds users:view but not users:manage. |
| Driver cannot see expenses | The Driver role deliberately excludes belege:view. |
Step 5: Fix the access
- Decide whether the user should have the permission at all.
- If yes, assign a role that carries it in the correct tenant, or add the permission to a custom role the user holds.
- Remember that changing a custom role's permissions replaces its whole permission set — include everything the role should have.
- Have the user sign out and back in so their session reflects the change.
Note: If you recently changed a role's permissions and the user still sees "Access Denied", a stale session is the usual cause. Re-authenticating refreshes their effective permissions.
Related
- The permission catalog and categories
- Assign permissions to a custom role
- Assign and remove user roles
- Who can assign the SystemAdmin role
