Troubleshooting and quick reference
Start with the failing layer and the exact target. Capture the tenant code, screen, operation, target identifier and displayed message. Never include passwords, bearer tokens or private setup links in support evidence.
Common problems
| Symptom | Likely check and recovery |
|---|---|
| Administration menu missing | Check operation permissions and current platform context; sign in again after role changes |
| User absent from list | Check search/pagination and administrator-target view protection |
| Edit or assignment button absent | Check server allowed actions, target protection and update authority |
| Permission visible but checkbox disabled | Read availability reason; inspect delegation ceiling and reserved powers |
| Assign Save/Assign disabled | Wait for complete original catalogue resolution; use Retry after load failure |
| Other roles/grants disappeared | Replacement semantics: reload and restore the approved complete final set |
| Role name changed but powers did not | Permissions control operations; names are descriptive |
| Role grant saved but staff still cannot work | Fresh sign-in, tenant capability, unit scope and domain prerequisites |
| Primary Business Unit required | Select at least one unit and choose one of those as primary |
| Clear All cannot save | Current form refuses an empty access set; use the approved offboarding procedure |
| Unit save failed midway | Reload; sequential requests can leave a partially saved state |
| Unit absent from choices | Check activity and tenant; active choices do not list every historical grant |
| Hierarchy update refused | Check self-parent/cycles and correct-tenant references |
| Module Enable unavailable | Check platform entitlement and required dependencies |
| Configured enabled Yes, Available now No | Check effective dates, entitlement, parent/module dependencies |
| Feature management visible but module rows hidden | Module view and feature authorities are independent |
| JSON refused | Use a documented object or null, with valid syntax |
| Appearance changed only for me | Preview is local; save draft and publish for tenant change |
| Restored appearance not live | Restoration writes draft; publish the reviewed saved draft |
| Owner cannot be edited or demoted | Protected owner boundary; use operator procedures |
| Setup link invalid | Check newest link, 30-minute expiry, tenant lifecycle and account state |
| Recovery did not enable disabled staff | Ordinary disabled accounts are not re-enabled by recovery |
| Operator page rejects tenant credentials | Use a separately provisioned platform identity |
| Operator session lost after reload | In-memory operator session; sign in again |
Safe diagnostic order
Frequently asked questions
Does SUPER_ADMIN mean every business operation is allowed? No. Delegation, execution permissions, capability enablement and unit/specialist scope are independent.
Does tenantGrantable mean everyone can assign the permission? No. It is eligibility for bounded delegation by an actor with the delegation authority, alongside required operation and target checks.
Can I create a permission in the catalogue? The current tenant Permissions screen is read-only. New implemented permissions and delegation eligibility are controlled release/operator work.
Can a parent business unit automatically cover all children? Do not assume it. Assign explicit operating scope and follow the domain's rules.
Does an invitation send email? No. The operator copies and privately delivers the setup link through a verified channel.
Can I set any company logo? The current Appearance page offers bundled logos. Original-art upload is outside the current workflow.
Are role edits automatically approved by a second person? No generic approval queue is implied. Follow your internal approval process; domain-specific two-person controls are separate.
Support handover template
Tenant: BHS
Screen: Authorization / Assign permissions
Target: approved role identifier and name
Requested operation: add one specific permission code
Observed result: exact displayed message
Original grants loaded: yes / no
Fresh sign-in tested: yes / no
Expected final set: approved non-secret role/permission list
Internal request reference: BHS-ACCESS-014
If a request may have saved before an error, reload before retrying. Report observed saved state separately from the intended change. Do not broaden access merely to make an error disappear.