Skip to main content

Users and roles

Users & Roles is a Super Admin control for creating or inviting user accounts, reviewing access, and changing assigned roles. Every person should use their own account so actions can be attributed correctly.

Use User roles and responsibilities for the full role model.

Before creating a user​

Confirm:

  • person's full name and approved email;
  • job responsibilities;
  • manager or business-owner approval;
  • lowest role needed;
  • start date;
  • whether access is temporary; and
  • who will provide training and review.

Do not create shared team accounts.

Inviting or creating​

  1. Open Users & Roles as Super Admin.
  2. Search to confirm the account does not already exist.
  3. Enter the approved identity information.
  4. Assign the lowest suitable role.
  5. Send the invitation or complete the supported creation process.
  6. Communicate access through a secure channel.
  7. Ask the user to sign in and confirm expected pages/actions.
  8. Complete first-day training.

Do not send passwords through personal chat or record them in activity notes.

Changing a role​

Before increasing access:

  • identify the exact task the user cannot perform;
  • determine whether the task belongs to their role;
  • confirm a configuration or account issue is not the cause;
  • obtain approval; and
  • define when access should be reviewed again.

After changing:

  • ask the user to sign out/in if required;
  • test with fictional records;
  • review the change in Audit Trail where available; and
  • document the reason.

Removing or reducing access​

Review immediately when a person:

  • leaves the business;
  • changes department or duties;
  • no longer needs temporary access;
  • loses authorization for sensitive work; or
  • is involved in a security concern.

Disable or reduce access according to the approved process. Do not rely only on telling the person not to use the account.

Periodic access review​

At a regular interval, Super Admin should compare:

  • active users;
  • current employment/role;
  • assigned platform role;
  • last known use where available;
  • temporary access end dates; and
  • high-trust Super Admin/Admin accounts.

Example: Staff requests Admin access​

A Staff user says they need Admin because Email Center is unavailable.

  1. Manager confirms whether sending email is part of the person's role.
  2. The specific workflow is reviewed.
  3. If only occasional sending is required, an existing Admin may perform it.
  4. If ongoing Admin responsibility is approved, the role change is documented and tested.
  5. Access is reviewed after the agreed period.

Common mistakes​

  • Giving Super Admin to solve a single permission issue.
  • Creating duplicate accounts for one person.
  • Sharing temporary credentials insecurely.
  • Leaving access active after duties change.
  • Testing access with live payments or contracts.
  • Assuming role visibility alone authorizes a business decision.

Suggested training media​

Screenshot space: Add a Users & Roles screenshot with fictional invited, active, and disabled users. Label role, status, identity, and available actions.
Screenshot space: Add a role-change example showing approval note, old role, new role, test result, and audit/history event.
Diagram space: Add an access lifecycle: Request → Approve → Create with least privilege → Train/test → Periodic review → Change/revoke.
Video space: Record a 5-minute Super Admin walkthrough inviting a fictional Staff user, confirming access, and safely reviewing a later role-change request.