User Management¶

User Management controls who can sign in to the portal, which entity they belong to, and which permission group determines their access. Changes take effect against the portal's user identity store, so create, group, password, and delete operations should be treated as security-sensitive administration.

Open Administration > Users. The available buttons and actions depend on your USERS permissions and whether you are a system administrator.

Users list¶

Users list

The cards at the top summarise:

Active Users — accounts currently enabled in the identity provider;
Disabled Users — accounts present but not currently enabled; and
Total Users — all accounts returned to the portal.

These counts are calculated from the complete loaded user list, not only the current search result or page.

The table contains:

Column	Meaning
Username	The user's portal display/sign-in name stored as the preferred username.
User Group	The first permission group associated with the user.
Account Status	Whether the identity account is enabled or disabled.
Email Address	The user's email and underlying identity username.
Confirmation Status	The identity-provider lifecycle state, such as requiring an initial password change or being confirmed.
Created	The date on which the identity account was created.
Actions	Edit and, where permitted, delete controls.

Search matches the user's Username or Email Address. Use the list/grid buttons to change the layout, and use pagination when more than four results match.

Understand account and confirmation status¶

Account Status and Confirmation Status answer different questions:

Account Status indicates whether the account is enabled.
Confirmation Status indicates where the account is in the identity-provider sign-in lifecycle.

A user can therefore be enabled but still unable to complete a normal sign-in because an initial password change or another confirmation step remains outstanding. When investigating access, check both columns before changing a password or recreating the account.

Common confirmation states can include:

Status	Meaning and next check
`FORCE_CHANGE_PASSWORD`	The user must sign in with the temporary password and choose a permanent password.
`CONFIRMED`	The identity has completed its confirmation step. Continue checking password, MFA, group, and entity if sign-in or access still fails.
`RESET_REQUIRED`	The identity provider requires a password reset before normal access.
`UNCONFIRMED`	The account has not completed the required confirmation flow.

The exact states shown depend on the identity-provider response.

Before creating a user¶

Confirm:

the person's approved work email address;
the portal username naming convention;
the entity to which the person belongs;
the least-privileged group needed for their work;
how the temporary password will be delivered securely; and
who will verify that onboarding and MFA are completed.

Search by email before creating a record. The portal uses the email address as the underlying identity username, so creating a second record is not the correct way to fix an existing user's access.

Create a user¶

Open Administration > Users.
Select Create User.
Enter the user's Username and Email.
Select the User Group.
Select the user's Entity.
Enter the initial Password.
Enter the same value in Confirm Password.
Review the entity and group carefully.
Select Create User.
Confirm that the user appears in the list and check the confirmation status.
Deliver the temporary password through an approved secure channel.

Create a new user

The create process stores the supplied email address as the underlying identity username, saves the visible Username as the preferred username, associates the selected entity, marks onboarding as incomplete, assigns the selected group, and sets the supplied password as the initial temporary password.

Create-user field guide¶

Field	Required	What it controls	Guidance
Username	Yes	The name displayed in the portal and audit-related user information.	Use the organisation's agreed convention and a name that remains recognisable.
Email	Yes	The user's email and underlying identity username.	Use a valid, unique work address. Verify spelling before creation.
User Group	Yes	The permission role assigned to the user.	Select the least-privileged group that supports the person's responsibilities.
Entity	Yes	The business entity with which the account is associated.	This scopes the account's business context. Only system administrators can select or change it in the current form.
Password	Yes	The initial temporary credential.	Must satisfy the displayed password policy. Do not reuse another system's password.
Confirm Password	Yes	Confirms the initial password was typed correctly.	Must exactly match Password.

Password requirements¶

The current form requires a password of at least eight characters containing:

an uppercase letter;
a lowercase letter;
a number; and
a special character.

The Create User button remains disabled while required fields are missing, the email is invalid, the password does not satisfy the policy, or the two password values differ. The eye buttons reveal or hide the entered values; use them only when nobody else can see the screen.

Warning

Never send a temporary or permanent password in a public ticket, shared channel, or documentation screenshot. Use the organisation's approved secure credential-delivery method.

User groups¶

The portal currently offers these groups:

SYSTEM_ADMINS
ADMINS
EDITORS
REPORTERS
VIEWERS

The names indicate the intended responsibility, but access is ultimately controlled by the portal's permission matrix for each feature and operation. Do not assume that seeing a menu automatically permits create, update, or delete actions.

Only a system administrator can assign the SYSTEM_ADMINS group. Other administrators do not see that option. System-administrator membership should be rare because it includes platform-wide administrative capabilities.

Use the role that matches the person's work:

System administrators manage platform-wide and security-sensitive configuration.
Administrators manage approved administrative and operational areas without system-administrator scope.
Editors perform permitted operational configuration changes.
Reporters work primarily with reporting features available to that role.
Viewers use the read-only features granted by the permission matrix.

Review the effective permissions whenever the permission matrix changes; group names alone are not a complete access specification.

Entity assignment¶

The entity associates the account with a customer, tenant, or business unit. It can affect which business data and records the user works with, so it must not be selected only for convenience.

In the current form, entity selection is editable only for system administrators. For other administrators it is locked. If a user must move to another entity, ask an authorised system administrator to make and verify the change.

After an entity move, review the user's group, expected pages, reports, and access to entity-owned services. Changing the entity does not prove that every previously cached session or external report has adopted the new scope; have the user sign out and back in, then verify access.

Edit a user¶

Find the user by username or email.
Select the pencil icon.
Review Username, Email, User Group, and Entity.
Change only the approved fields.
Leave Password and Confirm Password blank to keep the current password.
To reset the password, enter and confirm a new compliant value.
Choose whether the new value is a temporary password.
Select Save all Changes.
Confirm the user list shows the intended group and account information.

Edit a user

What can be changed¶

Field	Edit behaviour
Username	Updates the preferred username displayed by the portal.
Email	Identifies the underlying account in the current implementation. Treat it as the stable account key, not an ordinary editable profile field.
User Group	Replaces the existing group when a different group is selected. You cannot change your own group.
Entity	Updates the account's associated entity when edited by a system administrator.
Password	Optional during edit. Leave blank to preserve the existing password.
Confirm Password	Becomes required when a new password is entered.
Is this a temporary password?	Appears only while editing and only after entering a new password.

Important

The current update operation uses the email value to locate the underlying identity and updates the preferred username and entity attributes. It is not a dedicated email-address-change workflow. Do not change the Email field unless your identity-management procedure explicitly supports and has tested that operation.

Temporary or permanent password¶

When Is this a temporary password? is selected, the user is expected to replace the supplied password during the next authentication flow. Use this for administrator-initiated resets where the user should choose their own secret.

Clear the checkbox only when policy explicitly permits the administrator to set a permanent password. A permanent password known to an administrator creates avoidable security and accountability risk.

After a reset, communicate only that a reset was completed and deliver the temporary credential securely. Ask the user to complete sign-in and MFA without sharing their new permanent password.

Changing a group safely¶

Changing a group removes the previous group and then adds the selected replacement. Before saving:

Record the original group.
Confirm the target group's effective permissions.
Check whether the change grants access to configuration, billing, reports, or user administration.
Save the change.
Ask the user to sign out and back in so a new session reflects current group membership.
Test one page the user should access and one they should not.
Review Audit Logs for the administrative change where available.

The portal prevents a user from changing their own group. This reduces the risk of accidental self-demotion, self-escalation, or removal of the last known administrative access path.

Delete a user¶

The delete icon appears only when the current user has delete permission. It is hidden for your own account, so you cannot delete yourself through the list.

Deleting a user removes the identity account rather than merely disabling it. Use it only when the organisation's offboarding and retention procedure calls for deletion.

Before deleting:

confirm the exact username and email;
confirm that access should be permanently removed;
transfer any operational ownership or notification responsibilities;
preserve required audit or support information;
ensure another administrator remains available; and
obtain approval according to the access-management process.

The confirmation dialog identifies the user and requires an explicit delete choice. After deletion, search again to verify the account is absent.

Danger

Deletion is materially different from changing a role or resetting a password. Do not delete and recreate an account as a routine troubleshooting step.

Permissions for User Management¶

The current application permission matrix grants full Users create/read/update/delete access to SYSTEM_ADMINS. ADMINS can read, create, and update users but do not receive delete permission. Buttons are independently controlled by create, update, and delete checks.

If a user can open the page but an action is missing, check the permission for that exact action. If the entire Users page is missing, check the group's read/menu access and have the user establish a fresh session after any group change.

New-user verification checklist¶

The email address is correct and unique.
The username follows the naming convention.
The entity is correct.
The group grants only required access.
The user received the temporary password securely.
The confirmation status progresses after first sign-in.
The user replaces the temporary password.
MFA/onboarding is completed where required.
The user can access an expected page.
The user cannot access a restricted page.
The creation is visible in the appropriate audit trail.

Periodic access reviews¶

Regularly review:

disabled and unused accounts;
users who changed teams, customers, or responsibilities;
system-administrator membership;
accounts with unexpected entities;
users whose confirmation status never completed;
shared or generic addresses; and
accounts belonging to people who have left the organisation.

Use a named account for each person. Shared accounts weaken auditability and make password/MFA ownership unclear.

Troubleshooting¶

The Create User button is missing¶

The signed-in account does not have the USERS create permission. Ask a system administrator or authorised administrator to create the account; do not share credentials.

Create User or Save all Changes is disabled¶

Complete every required field.
Enter a valid email address.
Ensure the password satisfies the complexity policy.
Ensure Password and Confirm Password match.
On create, select both a group and entity.

Confirm the account is enabled.
Check Confirmation Status for FORCE_CHANGE_PASSWORD, UNCONFIRMED, or RESET_REQUIRED.
Confirm the user is entering the email/identity expected by the environment.
Reset the password only after checking the status and delivery of the original temporary password.
Check whether MFA or onboarding must still be completed.

Check the assigned group, the feature's read permission, the user's entity, and whether a fresh session was established after the change. Page visibility and action permissions are separate.

The wrong group was assigned¶

Edit the user, select the approved group, save, and have the user sign out and back in. Verify both allowed and restricted access and review the audit record.

A user needs a new email address¶

Do not simply overwrite Email on the edit form. Because email identifies the underlying account in the current implementation, follow the approved identity migration procedure or obtain guidance from the system owner.

User retrieval or saving fails¶

Confirm connectivity to the identity and application backends, then retry once. Record the username, time, action, and visible error without recording passwords. Check application logs and Audit Logs before creating a duplicate account.