Create a custom role

What this achieves

A custom role is one you define yourself, with its own dashboard type and set of permissions. You create one when the system roles supplied with Humavera do not match how your organization actually divides responsibility.

Required role: Administrator.

Before you start

Read the system roles first. They cannot be edited, but you can view their permissions — and if one of them fits, using it is less work than maintaining a custom role forever.

Steps

Go to Settings → Roles.
Select Create Role.
Enter the Name and a Description.
Choose the Dashboard Type.
Under Sensitive data, decide whether this role Can see people’s pay.
Work down the Permissions, unticking anything this role should not have.
Select Save.

System roles cannot be edited

Roles supplied with Humavera are marked System (read-only). You can open one and read everything it grants, but not change it.

That restriction protects you. A system role edited into something unrecognisable would break the assumptions the rest of the product makes about it, and it would change under the feet of everyone already holding it.

Duplicate is the way round it. It gives you an editable copy that starts out identical to the supplied role, which you then rename and narrow. That is usually less work than building a role from nothing, and it is how you make a version of a supplied role with one thing taken away.

Dashboard Type is the important choice

Option	Description
Admin	Company-wide reach.
Manager	Scoped to the holder’s own direct reports.
Instructor	Scoped to the learning they deliver.
Employee	Scoped to the holder’s own records.

The dashboard type decides scoping across the whole product, not only which menu appears. Permissions narrow what a role can do within that scope; they do not widen the scope itself.

Example: a custom role at HC Corp UK Ltd built on the manager type reaches its holder’s own reports. Granting it more permissions does not let it reach Finance — that would need the admin type.

If permissions have not been initialised

A workspace that has not yet seeded its permission catalogue shows a prompt to Initialize Defaults, which creates the standard permission catalogue. Roles cannot be configured meaningfully until that exists.

Do this once, before designing roles.

Permissions start from the dashboard type

The permission list is grouped under plain-English headings, with a row for each thing a role can act on and a column for each action — view, add, edit, delete, and the rest.

Every box starts ticked with what the dashboard type you chose can already do. Unticking is the edit. Only your differences are stored, so a role you leave alone behaves exactly as its dashboard type does today, including after the product adds something new to that type. The screen highlights the labels you have changed.

That is why the role list’s Permissions column reads Same as role type or a count of what you changed, rather than a number of permissions. The count you want is how far this role departs from its type, not how many boxes are ticked.

Grant what the role’s holders need to do their work and no more — access is checked on every request, so an over-granted role is genuinely over-granted, not merely untidy.

Example: an HR role at HC Corp UK Ltd that Sophie Clarke holds needs employee records and leave, and does not need payroll configuration. Unticking payroll is the difference between a scoped role and an administrator in all but name.

Where your plan does not include a module, its permissions are not listed — the screen says how many are hidden and confirms that anything already saved for them stays saved.

Deciding who sees pay

Sensitive data sits above the permission list because it works differently. It hides information rather than blocking a screen, so a role with Can see people’s pay turned off still manages its team as normal — salary is removed from the employee list and from profiles, and total rewards statements, bonuses and awards, and salary history are not available to it.

Everyone always sees their own pay, whatever this is set to.

Example: a team-lead role at HC Corp UK Ltd that runs one-to-ones and approves leave has no reason to read salaries. Turning this off leaves everything else about the role intact.

Deleting a role

Deleting a role cannot be undone. The role list shows how many users hold each role — check that count and move those people to another role before deleting, or they lose their access.

What happens next

The role becomes selectable when inviting a user or editing an existing one. Access changes take effect on the holder’s next request rather than at their next sign-in, so reducing a role’s reach removes it promptly — including on pages they have bookmarked.