People & Access

The People & Access screen is where you manage who can sign in to your workspace and what they are allowed to do. It lists everyone with an account, their role, and whether they are active; it is also where you invite new teammates, fine-tune permissions, and where each person can update their own profile and password. Because this screen controls access, a few of its actions are deliberately careful — they ask you to confirm and are recorded in your activity log. This guide walks through reading and searching the list, inviting a user, roles versus per-permission overrides, the permissions matrix, the keep-at-least-one-Admin rule, deactivating someone, and My Account.

Your users at a glance

The list shows one row per user with:

Name — links through to that user.
Email — the address they use to sign in (unique within your workspace).
Role — Admin, Manager, or Employee (covered below).
Linked Employee — the employee record this login is tied to, when set.
Status — Active or Inactive, shown as a labelled badge so it reads the same whether or not you can tell the colors apart.

Searching and filtering

Use the search box to narrow the list by name or email — it filters as you type. Above the list is a row of role pills — All, Admin, Manager, and Employee — each showing a count. Choose a pill to focus on one role; the counts stay put so you always see the full picture. All clears the role filter.

Inviting a user

Choose + Add User to invite a teammate. You provide their name, email, a role, and a temporary password. The email must be unique within your workspace. Choose Send Invite to create the account; the new user appears in the list right away with the role you chose.

Roles versus per-permission overrides

Every user has a role that sets their baseline permissions:

Admin — full control of the workspace, including billing, settings, and user management. Admins always have every permission.
Manager — broad operational access (jobs, dispatch, fleet, inventory, invoices, time approvals, financial entries, reports) without full company control or user administration.
Employee — limited self-service access: the time clock, edit requests, and read-only inventory.

On top of the role baseline you can layer per-permission overrides for Manager and Employee users — granting or revoking an individual permission for one person without changing the whole role. Admins are not customized per permission (they always hold everything).

The permissions matrix

Open Permissions to see the matrix: each Manager or Employee user is a column, each permission is a row, grouped into nine areas:

Jobs & Dispatch — jobs and the dispatch board. Dispatch has no separate permission of its own; the Jobs group covers it.
Employees — employee records.
Time — timesheets, the clock, edit requests, and time approval.
Invoices, Agreements & Payments — invoices, service agreements, and payments.
Financials & Reports — financial entries and reporting.
Quality Control — QC checklists.
Inventory — stock items and quantities.
Fleet — vehicles, fleet entries, and documents.
Users, Billing & Settings — user administration, workspace billing, and settings.

Toggle a permission on or off for a user, and QELM asks you to confirm first — “Grant permission to user?” — because changing access is a privileged action. Every grant or revoke is recorded in your activity log so there is always a trail of who changed what. The change is checked on the server, which has the final say on what takes effect.

The keep-at-least-one-Admin rule

Your workspace must always have at least one active Admin. If a change would remove the last active Admin — for example demoting or deactivating the only one — QELM rejects it and tells you why. This is enforced on the server, so it holds no matter how the change is attempted. It exists to make sure no one can lock the whole workspace out of its own administration.

Deactivating and restoring a user

When someone leaves, Deactivate them from the row actions. QELM asks you to confirm first — deactivating keeps the record but stops the person from signing in. A deactivated user can be Restored later. Nothing is deleted; deactivating just removes access while keeping the account on file. (The full user-record edit — name, email, the active flag, and the employee link — currently happens on the classic user screen; the role and per-permission overrides are edited on the permissions matrix.)

My Account

Every signed-in user can open My Account to update their own profile name and change their own password — and only their own. The password change asks for the new password twice to confirm it, and the change is applied securely on the server. This is the self-service screen; managing other people’s accounts is done from the main People & Access list and the permissions matrix.

Deleting your own account

A user can ask for their own account to be deleted — it is not something an administrator does to someone else. The request is made from the account’s own settings.

What happens when it is made:

The account is deactivated immediately. The person can no longer sign in, and they disappear from the working lists.
There is a 30-day grace period. During those 30 days the deletion can be undone by signing back in, which restores the account.
After 30 days, the personal data is permanently erased. That step cannot be undone.

Money records are kept. Payments and invoices survive the erasure, because they are business and tax records that have to. What goes is the personal identity attached to them: the records are anonymized rather than deleted, so your books still balance and your history stays intact, but the person is no longer identifiable in them.

A note on what you see

The People & Access screen shows only your own workspace’s users, and your role determines what you can do here — user administration is an Admin capability. If the list looks short, it usually just means few people have been invited yet; it fills in as you add teammates. For how roles map onto the rest of QELM, see the Guides overview.