Administration

Users, roles & permissions guide

This is the guide behind every “ask an administrator to grant the permission” message in HumanR. It explains how access works — roles hold permissions, and people are given a role — how to create accounts and employee logins, and how passwords and sign-ins are handled.

This is the guide HumanR users read inside the product, published as-is. It is written for someone with the screen in front of them, so it describes buttons you cannot click from here — which is rather the point: you can check how the product behaves before you commit to it.

Roles, permissions & Admin

HumanR controls access in two layers, and it's worth getting the vocabulary straight:

A permission is one thing a person is allowed to do — “view payroll”, “manage leave”, and so on.
A role is a named bundle of permissions — for example HR or Viewer. You don't give permissions to people directly; you give them a role, and the role carries the permissions.

If someone says a menu or button is missing, it's almost always because their role is missing a permission. The fix is to add that permission to their role (or move them to a role that has it).

Admin is special. The Admin role can do everything automatically — it isn't listed in the permission grid and its permissions can't be edited, because it always holds them all. HumanR also protects the last Admin: it won't let you lock or demote the only administrator left, so you can never lock yourself out of the system.

The built-in roles

HumanR ships with five roles you can use as-is or adjust:

Role	Typical use
Admin	Full control of everything, including this screen.
HR	Day-to-day HR and payroll work.
Viewer	Read-only access for people who need to look but not change.
SiteReporter	Submits the daily deployment report from a site.
Employee	Self-service only — an ordinary staff member seeing their own information.

These five can't be renamed or deleted, but you can change the permissions on all of them except Admin. The Employee role deliberately carries just one permission — self-service access.

Create & edit roles

On Roles you can build your own roles to fit how your company works:

Start from another role. When creating a role you can copy an existing one's permissions as a starting point — “like HR, but without payroll” — then tick or untick from there.
The permission grid. Editing a role shows every permission grouped by area; tick what the role should be able to do.
Reset to defaults puts a built-in role back to how it shipped.
Delete is available only for a role that no one is assigned to.

Many areas split into View and Manage — View lets someone see a screen, Manage lets them change things there. Grant the narrower one when in doubt.

When changes take effect

A permission change isn't always instant for someone already signed in. It takes effect the next time their session is refreshed — within a few minutes — or immediately if they sign out and back in. If you've just granted access and the person still can't see it, ask them to sign out and in again.

Add a user & assign a role

On Users, Add user creates an account and gives it a role. A few rules:

Username is unique and can't be changed later — choose it carefully.
Email is optional, but it's needed for security alerts and any email the system sends that person.
Password must be at least 8 characters.
You assign exactly one role; change it any time from the same screen.

You can lock an account to suspend access without deleting it — except, as noted above, the last Admin.

Employee logins & ESS access

Employee logins (under Users) is where you connect a HumanR account to a staff record so a person can use self-service — see their own payslips, request leave, and so on. The connection is one-to-one: one account per person.

Generate ESS access creates the account and produces a one-time printed slip with the sign-in details to hand to the employee. For security it is never emailed — you print or copy it once, at that moment.
Provisioning many at once is safe to re-run: people who already have access are skipped, so you won't create duplicates.
You can unlink an account from a person if you need to.

Self-service pages only exist if the ESS module is switched on for your instance. What staff see there is covered in the Employee Self-Service guide.

Passwords & sessions

Passwords are reset by an administrator, not changed by users themselves. When you send a reset for someone:

All of that person's active sessions are signed out immediately.
A security-alert email goes to them (if they have an email on file).

HumanR manages sessions the way large web services do: each sign-in is a tracked session, a person is alerted when a new device signs in, and any session can be signed out remotely. Users can review and end their own sessions from their account.

Because there's no self-service password change, keep at least one contactable Admin — resets always go through an administrator.

Permissions & gotchas

Users · Manage — the single permission for this whole area (accounts, roles, employee logins). It's an administrator-level capability.
The Employee-logins screen also needs Employees · View to find people, and the self-service buttons there appear only when the ESS module is on.

Worth remembering

Access is role-based: change what a role can do, or move the person to a different role.
Admin holds every permission automatically and can never be reduced below one administrator.
Permission changes land within a few minutes, or right away on next sign-in.
Usernames are permanent; passwords are admin-reset only, and a reset ends all that user's sessions.
ESS slips are shown once and printed, never emailed.

Users, roles & permissions guide

Questions this guide did not answer?