Users and Roles

Under System Control → System Users.

Two screens that work together and are often confused:

• A user is a person who can log in.
• A role is a named set of permissions.

Every user is given a role, and the role decides what they can see and do. You control access by editing roles, not by editing people one at a time.

Roles

System Users → Roles

Each role is a named bundle of permissions — typically Company Administrator, HR, Manager and Employee, though you can create your own.

Editing a role shows the full permission list, grouped by module, with a checkbox for each. Permissions generally come in families for each screen: manage, create, view, edit and delete.

Permissions decide what appears in the menu, not just what is allowed

If a role lacks the permission for a screen, that screen is not in the sidebar at all for anybody with that role. It is not greyed out; it is absent.

This is why “the menu item is missing” and “I do not have permission” are the same problem in this system. Users report the first; you fix the second.

Changing a role changes it for everyone who has it

Roles are shared. Granting payroll access to the Manager role grants it to every manager in the organization, immediately.

If one person needs something extra, create a role for that case rather than widening a role that many people hold.

Permissions worth thinking about carefully

Some permissions expose considerably more than their name suggests:

Permission area	Why it needs care
Payroll, Payslips, Employee Salaries	Everybody’s pay. Rarely appropriate outside HR and finance.
Complaints	Frequently names a second employee who does not know the record exists.
Warnings	Disciplinary records, with legal weight.
Users and Roles	Anybody who can edit roles can grant themselves anything.
Settings	Can change email, storage and payment configuration for everyone.

Role editing is the permission that contains all the others

A user who can edit roles can give themselves every other permission in the system, and then use it.

Treat it as the equivalent of handing over the keys, and keep it to as few people as your organization can manage with.

The Permissions screen

There is a separate Permissions screen in the application, which lists the individual permissions themselves rather than the roles that bundle them.

Not normally reachable, and not normally needed

The Permissions screen is guarded by its own manage-permissions permission, which the company administrator role does not hold in a standard deployment. Visiting it directly returns a permission error, and it does not appear in the sidebar.

This is deliberate. The individual permissions are defined by the application; your job is to decide which roles get which of them, and that is done entirely on the Roles screen. You are not missing anything you need.

Users

System Users → Users

The accounts that can log in: name, email, role, and whether the account is active.

Employees and users are related but not the same

Creating an employee record creates a person in the HR system. Creating a user creates a login.

An employee normally needs both, and creating an employee usually creates the matching account. But not every user is an employee — an external accountant might have a login and no employee record — and an employee record can exist with no login at all.

If somebody cannot log in, check they have a user account, not just an employee record.

Adding a user

1. Add the user and enter their name and email. The email is their username and must be unique.

2. Assign a role. This is the decision that matters — it determines everything they can see.

3. Set a password, or use the system’s method for having them set their own.

4. Save, and confirm the account is active.

5. Tell them how to sign in. See Signing In.

When somebody leaves

Deactivate, do not delete

Deleting a user account can take its history with it, and history is the thing you will want later.

Deactivating leaves the record and the audit trail intact while making the account unusable. Deactivate on the last working day — not the following week.

Offboarding involves more than the account. See Offboarding Someone.

Login History

Login History

A record of sign-ins: who, when, and from where.

Worth looking at occasionally rather than only after something has gone wrong. Two patterns are worth noticing: accounts signing in from places your organization does not operate, and accounts that have not been used for months, which are usually people who have left.

Restricting where people can sign in from

If you need to limit access to particular networks, that is Settings → IP Restriction Settings rather than anything on this screen. See Settings.

Common questions

Somebody cannot see a screen they need. Find their role, and check the permission for that screen. Change the role, not the person — unless only that one person should have it, in which case make a new role.

Somebody can see something they should not. Same fix, in reverse. Then check who else holds that role, because they can see it too.

A user forgot their password. They can reset it themselves from the login page if email is working. If it is not, an administrator can set a new one.

Can two people share an account? They can, and they should not. Shared accounts destroy the audit trail — Login History and every record’s history become meaningless.

How many administrators should we have? More than one, so you are not locked out when somebody is on leave. Not many more.