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.
Set the Permissions for each resource.
Select Save.

System roles cannot be edited

Roles supplied with Humavera are marked System (read-only). You can open one and view its permissions, but not change it. To customise, create a new role.

That restriction protects you. A system role edited into something unrecognisable would break the assumptions the rest of the product makes about it.

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

Permissions are set per resource. 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. Leaving payroll ungranted is the difference between a scoped role and an admin in all but name.

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.