Admin Governance: Change Reviews, Delegated Admins and Access Hygiene

Settings › Command Center is one list of what a workspace still has to do. It has three sections: setup progress (defaults that were never chosen, such as a base currency, a country on the organization profile, a warehouse or a tax), controls that are switched off (administrators without MFA, no value-based approval rules, sensitive changes that need no second person), and stale configuration (API keys nobody uses, dormant users, devices not seen for months, a security policy unchanged for over a year, change reviews left waiting). Each alert names the permission needed to see it and links to the screen that fixes it, so a delegated or partial admin only sees what they could act on. The command center reads; it never changes a setting itself.

Industry setup templates live under Settings › Setup Templates. There are five: retail shop, wholesale and distribution, manufacturing, NGO and donor-funded, and professional services. A template proposes inventory defaults, a workflow pack, starter roles, reports and notification choices for that kind of organization. Its one rule is that it fills gaps and never overwrites: a value the workspace already chose is reported back as kept, not replaced. Preview shows exactly which values will be set and which will be kept before anyone presses Apply, and each apply is recorded with its changes and audited.

In practice: a distribution company in Mombasa signs up, sets its base currency and one warehouse, and then opens the command center. It shows no tax switched on, administrators without MFA and no approval rules. The administrator previews the wholesale and distribution template, sees that the currency and warehouse are kept and that inventory defaults, the distribution workflow pack and starter roles will be added, and applies it. The setup list shrinks, and the remaining alerts are the controls only a person can decide, starting with MFA for administrators.

A change review holds a sensitive change until a second person accepts it. Settings › Change Reviews lists the actions that can be held: weakening the security policy (MFA, sessions, passwords, SSO, lockout, IP or device rules; tightening applies at once), creating or rotating an API key, tax settings, inventory defaults, approval rules, and scheduling the whole organization for deletion. Each one is a switch, and every switch starts off. A workspace turns on only the actions its own policy names. While any switch is on, switching one off is itself held for review, so the person a guard is meant to check cannot quietly remove it.

When a held change is submitted, the person states a reason and AWRA records what the setting was and what it will become. Someone else in the workspace who holds the Review sensitive changes permission approves or rejects it; the requester can never decide their own, and a rejection needs a comment. Approval applies the change through exactly the same path as an unguarded save. A request nobody decides expires after 72 hours. For an API key, the requester sees the new secret once, after approval. Every request, decision and application is written to the audit log under Change Review, and approvers can work the queue on the web, through the API or in the mobile app.

A one-administrator workspace still benefits. When nobody else can approve, the requester may approve their own request once 24 hours have passed since submitting it. The request is then marked self-approved, and the audit entry says so, so the fallback is visible as what it is: a delay, not a second pair of eyes. In practice: a finance lead at an NGO switches on reviews for tax settings and approval rules. A colleague tries to delete the 16% VAT rate; the change waits, the finance lead sees the before and after, rejects it with the comment that the rate is still in use, and the rate is untouched.

A delegated admin is someone who manages users and roles inside a boundary, without being a full Admin. Settings › Delegated Admins offers five types: branch or warehouse admin, department admin, finance admin, security admin and implementation partner. A branch admin must be given at least one warehouse and a department admin at least one department, and they then manage only the people placed there. Whatever the type, a delegate never manages an Admin, never edits themselves, never touches someone whose current access goes beyond what they could grant, and can grant only permissions that their type allows and that they hold themselves. Permissions that create more administrators are removed from every type. Setting up delegates needs Manage delegated admins.

Before a role is saved, the role impact preview shows what the change would do to the people who hold it: which menu entries appear or disappear, which API routes start or stop answering, which mobile app screens open or close, and which segregation-of-duties pairs the change introduces. Each answer is read off the real gates, and a permission the plan does not include is shown as opening nothing. It turns "add a permission and see who complains" into a decision made before anyone is affected.

Bulk user actions apply one lifecycle change, such as suspending or reactivating, to many people at once, and a reason is required. Each person is checked on their own: same workspace, not yourself, inside a delegate’s boundary, and never the last active Admin. A person who fails a check is skipped with a sentence explaining why rather than failing the whole batch, and every change carries the reason and one shared batch id in the audit log. In practice: when a seasonal team of 40 leaves, the HR lead suspends them in one batch with the reason end of season, and the auditor can later pull the whole batch by its id.

Settings › Stale Access lists access that has outlived its use, in five groups: dormant users (active accounts nobody has signed in to for 90 days, or ever once the account is older than a 30-day grace period), unused roles (held by nobody, or only by deactivated people), risky combinations (active people holding both halves of a segregation-of-duties pair), old API keys (unused for 90 days, or older than 365 days whatever their use) and devices (waiting for approval, or still trusted though unseen for 90 days). The page is read-only. Each finding links to the screen that already owns the fix, so suspending a user, deleting a role, revoking a key or revoking a device is done where it always was.

The compliance evidence pack, under Compliance › Evidence Packs, gathers what an access audit asks for into one download. Alongside the audit log, approvals and security incidents, it can now include users and their access, roles and permissions, permission and admin changes, a snapshot of workspace settings, and AWRA staff access to your workspace. Every pack carries a control map that lists each control an auditor asks about, the framework clauses it relates to, and which sections of the pack evidence it, and shows the sections that are missing. The control map is a cross-reference to help your own audit; it is not a certification, and AWRA does not claim one.

In practice: before a quarterly access review, the security admin opens Stale Access and finds six dormant accounts, two unused roles and one API key created for a pilot that never went live. They suspend the accounts in a bulk action with a reason, delete the roles, revoke the key, and then build an evidence pack with the users, roles and admin changes sections for the quarter. The pack shows both the clean-up and who did it.