ICT & System Administrators

Administrators keep the suite running for everyone else: people can sign in, see the right menu, and their requests reach the right desk. This page is the daily and weekly routine; the Administration section has the detail.

Who this is for

ICT Administrator

Role ICT_ADMIN, for officers of the ICT unit (DAO-ICT) who support users. Settings, mail control, roles, user support, registries and the audit log, but not approval routes, request templates or voucher types.

System Administrator

Role ADMINISTRATOR: every permission in the suite. Keep this to two or three people.

The Head of ICT is also a head of unit: ICT Support & System Access requests (DAO-ICT-002) end on their desk.

What you’ll see in your menu

A System Administrator sees every item. The menu is long, so it is shown in two parts:

1. My Desk. Anything waiting on you, like everyone else.
2. Registry. Every registry office and the global registry.

1. Users. Accounts, passwords, onboarding and each person’s permissions.
2. Approval routes. Reusable approval workflows for vouchers and memos.
3. Request Templates. Forms, printed templates and approval chains for requests.
4. Settings. Modules, appearance, terminology, notifications and system health.

The ICT Administrator’s menu:

The System Administrator’s menu (every item):

Your working day

Every day: user support

1. “I can’t sign in.” Point them to Find your account & reset password first. If that fails, open them in Users and use Reset Password. A System Administrator can also reset Onboarding to send them through first-time setup again.
2. “I can’t see X in my menu.” Open the person in Users and look at their permissions. Compare with Roles at a glance. Apply the right role, or add the single permission. See Roles & permissions.
3. “My request is stuck.” Open it: the banner says whose desk it is on. If nobody holds that office, the unit has no head. Set one in Departments & Units and the step moves to them.
4. Mail. Create and assign mailboxes in Mail Control. See Mail domains & mailboxes.

When an office changes hands

For example, a new DFA, Checking head or Head of Audit:

1. Set the new head of the unit in Departments & Units. New and pending approval steps for that office move to them.
2. Apply the office role to the new holder (for example Director of Finance & Accounts) and the ordinary role to the person leaving, in Role & Permissions.
3. Check that the new holder’s menu matches the office. See Departments, units & heads.

Once a week

• Read the Audit Logs for unexpected changes: roles and permissions, settings, deleted records. See Reviewing the audit log.
• Check Settings › Health and the Notifications tab (send yourself a test notification). See System settings.
• Look for units without a head and users in no unit.

As needed (System Administrators)

• New or changed request templates, their forms and approval chains: Build a request type and Approval workflows.
• Memo templates and voucher types: Memo templates, Payment types.
• Which units are registries: Registry offices on the Registry page (ICT Administrators can do this too). See Registry offices.
• Bulk imports of staff: Add, import and manage users.

How do I…

The whole Administration section is written for you.

Things only you can do

• Change roles and single permissions for anyone.
• Change system settings: modules on or off, the hospital’s terminology, branding, whether a comment is required on every decision, where finished records are dispatched.
• Manage mailboxes and mail domains.
• Choose the registry offices.
• Build request templates, approval routes and voucher types (System Administrators).

Common pitfalls

• A role is a template. Applying it copies its permissions onto the person. Changing the role later does not change people who already have it: re-apply it to them.
• Head of unit is not a role. Approval steps follow the head of a unit. Setting the head without applying the office role leaves the person with tasks they may not be able to open fully, and the reverse leaves the office’s steps with the old holder.
• Re-running the UATH seed re-applies the Employee template to every user whose role is employee (office holders excepted). People you gave an extra role by hand, such as Clinical Staff or Procurement, lose it. Use --no-permission-sync when that matters.
• Testing as someone else. Use the @uath.test accounts on the local test system only. Never create test users on the live system.
• Deleting instead of deactivating. Deactivate leavers so their signatures stay on old records.

Related

• Administrator overview
• Every permission explained
• Troubleshooting & FAQ