Administration
Manage users, the command hierarchy, and review the audit log
The Admin menu item is visible only to admin-tier roles: Command Lead, Program Admin, and System Admin. It has three areas: users, commands, and the audit log.
Managing users
User management. Roles and command assignments are editable here; only System Admins can grant or revoke admin-tier roles.
Government accounts are created here — there is no self-registration on the government side.
Rules the system enforces:
| Rule | Why it matters |
|---|---|
| A Command Lead can only manage users assigned to their own command. | Not the commands below it — there is no downward inheritance. |
| Only a System Admin can grant or revoke admin-tier roles. | Prevents administrators from escalating their own reach. Other admins can only assign the non-admin roles (GOV_READONLY, GOV_POC). |
| Nobody can change their own account here. | Prevents self-escalation and self-lockout. Ask another administrator. |
| Admin-tier accounts cannot be managed by non-System-Admins. | Same reason. |
| The last System Admin cannot be removed or demoted. | Prevents locking everyone out of the system. |
Choose the least role that does the job: read-only for people who only need visibility, POC for people who record engagements, Command Lead only for those who publish to industry.
Every user change is written to the audit log with your account attached.
Managing the command hierarchy
Open Admin → Commands. Every admin can read the hierarchy here, but only a System Admin can change it: adding a command, editing its details (name, abbreviation, echelon, location, mission), removing one that is no longer needed, and changing which command it reports to are all System Admin actions.
The command hierarchy, shown read-only — a System Admin reorganizes it.
Reparenting is deliberate, and System Admins only
Reparenting a command changes the reporting structure everyone reads on the Commands & Portfolios page — it is not cosmetic. It does not change who can see what: Command Leads only ever see their own command, whatever it reports to. Only a System Admin can do it. The system refuses to make a command its own parent or to create a loop, but it cannot tell you whether a reorganisation is correct. Agree the change with the program office first, and do it once, deliberately.
A command cannot be deleted while records still depend on it. If a command is standing down, leave it in place; deleting it would orphan its engagement history.
The audit log
Open Admin → Audit. Available to Program Admins and System Admins only. It is read-only — nothing here can be edited or deleted.
The audit log: the most recent authentication, admin, and data-access events, filterable by category.
The page lists the most recent events (up to 200) with four columns:
| Column | Meaning |
|---|---|
| Time | When it happened. |
| Event | What happened — sign-in, authorization failure, status change, publication, administrative change, export. |
| User | Whose account did it. |
| Detail | Extra context about the specific record or change. |
Use it to answer "who changed this and when", to check whether a failed action actually happened, and to review authorization failures — a burst of them usually means someone's role does not match what they are trying to do.
For anything older than the most recent 200 events, or for a formal review, ask the program office; the log is retained beyond what this page displays.