Administrator overview

Where everything an administrator looks after lives in the suite, what to set up first on a new installation, and how to change things without disturbing work that is already in progress.

This section is for System Administrators and ICT administrators, and for HR officers who manage staff records. If you are new to the suite as a user, start with Quick start in 5 steps and ICT & System Administrators.

Names on this installation. The hospital's own words replace some of the suite's default labels (see Terminology). This manual uses the hospital's words and gives the default in brackets the first time, for example Departments & Units (User Groups), Request Templates (Request types), Voucher Types (Payment types), Approval routes (Approval workflows) and My Desk (Approvals).

Where everything lives

Administration pages sit in two groups of the menu on the left. You see an item only if you hold its permission (in brackets below). System Administrators hold every permission.

Menu item	What you manage there	How-to
People › Users (`view_users`)	Staff accounts: add, edit, deactivate, reset passwords, reset onboarding, per-person permissions, export.	Add, import and manage users
People › Departments & Units (`view_user_groups`)	The organisation tree: departments, units, their codes and heads.	Departments, units & heads
Administration › Role & Permissions (`view_roles`)	Role templates: named sets of permissions you copy onto people.	Roles & permissions
Administration › Request Templates (`view_request_types`)	Each kind of request: its form, its printed document, its approval chain, who files it and who receives it.	Build a request type
Administration › Approval routes (`manage_approval_workflows`)	Reusable approval chains for payment vouchers and memos.	Approval workflows
Administration › Memo templates (`view_memo_templates`)	Letterhead, header fields, numbering and approval route of each kind of memo or circular.	Memo templates
Administration › Voucher Types (`manage_payment_types`)	Each kind of payment voucher: its form, printed voucher and approval routing.	Payment types
Work › Registry (`manage_registries`)	Which units are registry offices that file finished requests.	Registry offices
Administration › Mail Control (`view_mail_control`)	Mail domains, shared mailboxes, who can open them, and the external mail policy.	Mail domains & mailboxes
Administration › Settings (`view_settings`)	System variables, modules on/off, colours, terminology, notification and health checks.	System settings
Administration › Audit Logs (`view_audit_logs`)	The record of who did what, and when.	Reviewing the audit log

For a full list of permissions and which standard roles hold them, see Every permission explained and Roles at a glance.

First-day setup checklist

On a fresh installation the hospital's reference data (the unit tree, role templates, request templates, approval routes, voucher types, memo templates and default settings) is loaded by the ICT team with the seed script npm run db:seed:uath. After that, work through this list in the app.

Check the system is healthy. Open Settings › Health and confirm All required checks passing. Fix anything red before inviting staff. See Health.
Check the organisation's details. In Settings › Variables, confirm org.name, org.short_name, org.address and org.email_domain, and the approval rules (approvals.require_comment, approvals.require_signature, approvals.allow_return). See Useful variables.
Check the wording. Settings › Terminology holds the hospital's words. Change them only if the hospital asks.
Switch off modules the hospital does not use. Settings › Modules. A module that is off disappears for everyone.
Review the unit tree and heads. In Departments & Units, check that each department and unit has the right head. Heads decide the first level of most approval chains. See Departments, units & heads.
Load the staff. Bulk-import the nominal roll, or add people one at a time. Put each person in their unit. See Add, import and manage users.
Give office holders their permissions. The CMD, CMAC, DA, DFA, finance, audit and registry staff need more than the Employee template. See Office holders.
Check the registries. On Registry, select Registry offices and confirm which units file finished requests. See Registry offices.
Walk one request through. As a test person, submit a request of a common type and approve it at every level. Check who received each step, the printed document and the registry copy.
Set up mail if the hospital uses the suite's mailboxes: domains, shared accounts and the external mail policy. See Mail domains & mailboxes.

Making changes safely

Most administration screens change what happens next, not what already happened. Knowing which is which keeps you out of trouble.

When you change…	Work already in progress	New work
A request template's form, document or chain	Keeps the copy it was submitted with. A step that has not opened yet is assigned again when it opens.	Uses the new version at once.
An approval route	Finishes on the version it started with. Saving creates a new version.	Uses the new version.
A memo template	Memos keep the template copy they were written from.	Uses the new template.
The head of a unit	Pending approvals the old head held as head of that unit move to the new head automatically.	Routes to the new head.
A role template	Nothing changes for people who already have it.	Only people you copy it onto from now on get the change.
A person's permissions	Take effect at once. The person's menu catches up the next time their page reloads.
Terminology	Only the words on screen and in new documents change. Stored statuses and reports do not.

Good habits

Deactivate rather than delete. Users, units, request templates, voucher types and memo templates that have history can only be deactivated, and deactivating keeps the record. Delete only things created by mistake.
Preview before you save. Request templates, approval routes, memo templates and voucher types all have a preview. The approval route preview shows exactly who would get each step for a person you choose.
Test with a test person. Sign in as one of the test accounts, not a real member of staff, when you check a change.
Change one thing at a time and check the audit log afterwards. Every administration change is recorded there with the before and after values.
Keep the seed in mind. Re-running the seed script re-applies office templates and fills gaps. It does not overwrite forms, templates and chains unless it is run with --refresh-types, which rewrites the seeded ones and loses changes made in the app.

Some switches save the moment you flip them, with no Save button: the external mail policy in Mail Control is one. Read the description beside a switch before you touch it.

Jobs done from the command line

A few jobs have no screen and are run by the ICT team on the server, from the application folder:

npm run users:import: Bulk-create staff from the nominal roll spreadsheet. See Bulk import.
npm run db:seed:uath: Load or top up the hospital's reference data and re-apply office templates.
npm run permissions:backfill: Bring every stored role and person up to date after an upgrade adds permissions. See After an upgrade.
npm run users:mark-onboarding: Send existing staff who have no photo or signature through first-time onboarding.
npm run users:dedupe-staff-ids: Report staff numbers or IPPIS numbers shared by more than one person, which make staff-ID sign-in ambiguous.