Administration and access control
Manage staff access, site-wide policy and administrative oversight from the protected dashboard.
- Open the dashboardSign in with your assigned account and use the Administration links in the dashboard sidebar. If a link is absent, your role does not grant that function.
- Check access before actingGod can use all administrative controls; admin and superadmin have the general administration area, while several global settings remain God-only.
- Make a bounded changeOpen the relevant record, check its current status and related items, then change only the requested fields. Treat role, authentication and publication changes as security-sensitive.
- Save and confirmSubmit the form and check the success notice and resulting record state. Validation errors identify fields to correct; do not retry a sensitive action until its prior result is clear.
- Keep an audit trailUse the Audit Log to search or export administrative events. Record an accurate reason wherever the screen requests one, and verify the event after consequential changes.
Dashboard access and roles
The sidebar is role-aware: admin, superadmin and God have general administration, while selected global controls are God-only. Roles edits existing permission assignments; it does not create general-purpose roles. Check a role and its users before changing shared access.
- Open Roles and select the role being reviewed.
- Compare permissions with the approved duties; remove unrelated access.
- Save and confirm the intended dashboard links.
User administration
Users supports search, detail, create/edit, status changes, bulk actions and export. Check account state and role before changing them. Wallet credit is a separate financial action. Impersonation is controlled administration, not a substitute for the user’s authentication or a protected step-up check.
- Find and open the verified account record.
- Change only the requested profile, role or active state.
- Re-open the record to verify the result; resolve errors before retrying.
Site theme and sign-in policy
The God-only Site Authentication and Theme page controls site-wide theme policy and normal versus SSO sign-in. Save only the approved setting, then check the public entry and login route. User theme preference is separate and lives in the profile.
- Read the current policy on Site Authentication and Theme.
- Select the authorised mode or theme and save.
- Check the entry point and resulting login form; reopen settings if unchanged.
Audit and evidence
Audit Log supports filtering, event detail and export. Inspect actor, action, entity and metadata, then verify the affected record separately. Editorial changes can retain before/after values and a reason. Treat exports and personal data as restricted.
- Filter to the relevant date, actor or action.
- Open the event and compare it with the affected record.
- Export only when needed and store it in an authorised location.
Safe administration practice
Use the smallest role capable of completing a task. Several controls require God even when an administrator can see related dashboards. Fresh MFA is required for especially sensitive backup operations; genuine step-up checks must be completed through the normal flow. Keep provider secrets and customer identifiers out of notes and documentation. For bulk actions, review the selected rows and expected impact before submission. When an operation is asynchronous, use its status or audit record rather than submitting the same action repeatedly.
- Confirm the account role and any fresh-authentication prompt before making a change.
- Review the target and scope, and enter a useful reason where the form requests it.
- Check the resulting record and audit entry; escalate a mismatch instead of compensating with another broad change.
Troubleshooting access
A missing menu entry usually means the current role or resource-specific permission does not include it. A forbidden response means the server-side policy also denied the action; do not work around it through another account. If the page loads but a save is rejected, read field-level validation errors and confirm required fields and allowed values. If a change is accepted but not visible, reload the record and consult its audit event before trying again.
- Check your current role and the resource-specific access assignment.
- Read the visible error and correct only the rejected field or required step.
- Ask the authorised role owner to grant the minimum approved permission if access is genuinely missing.
Frequently asked questions
Why can I not see a control?
The dashboard hides links by role, and some server actions require stricter permissions than the general admin area. Ask the role owner to confirm the minimum required access.
Can an admin change every site setting?
No. Several global settings are explicitly restricted to God, including site authentication policy and backup operations.
Where do I verify a change?
Re-open the affected record and, for consequential administrative changes, check the Audit Log for the corresponding event.
Can I use impersonation to bypass a missing role?
No. Impersonation is not a permission workaround and does not replace normal authentication, authorisation or step-up checks.
What should I do after a validation error?
Correct the field named by the form, check the current saved record, and submit once. Do not repeat an action whose outcome is uncertain.
Should I put credentials in an audit reason?
No. Reasons should explain the business purpose without passwords, provider keys, private host details or unnecessary personal data.