Setup Considerations: roles and permissions

What this achieves

A role decides what a person can reach in Humavera and what they can do there. Designing the set of roles before people are assigned to them is far easier than restructuring afterwards, because every change moves what real users can see.

Decision 1: whether you need custom roles at all

Humavera ships system roles, and those cannot be edited — you can view their permissions but not change them. Customising means creating a new role rather than adjusting a supplied one.

Start by reading the system roles against what your organization actually needs. Many mid-market companies never need a custom role, and every custom role you create is one more thing to keep correct as the product grows.

Create a custom role when a real group of people needs a genuinely different reach — not to rename an existing one.

Decision 2: the dashboard type behind the role

Every role sits on a dashboard type: admin, manager, instructor, or employee. That choice is more consequential than the permission list, because the dashboard type is what the rest of the product reasons about.

Navigation, scoping, and route access are decided by dashboard type throughout Humavera. A manager sees their own reports because they are a manager, not because of a permission tick.

Example: a custom role at HC Corp UK Ltd built on the manager dashboard type inherits manager scoping — its holders see their own reports, not the company. Building the same role on the admin type gives company-wide reach, whatever else you configure.

Choose the dashboard type by asking whose data the role should reach, then use permissions to narrow within that.

Decision 3: how many roles

Option	Description
Few, broad roles	Simpler to reason about and to audit. Some people get slightly more reach than they strictly need.
Many, narrow roles	Tighter access. More roles to maintain, and more chances for someone to end up in the wrong one.

The maintenance cost is the one people underestimate. Every new module and every new page has to be considered against every role you have created.

Example: HC Corp UK Ltd’s People department of six does not need a separate role per person. One HR role covering what that team does is easier to keep correct than six.

Decision 4: initialise permissions first

A workspace that has not yet seeded its permission catalogue cannot have roles configured against it. Humavera tells you when that is the case and offers to initialise the standard catalogue.

Do this before designing roles rather than discovering it mid-way.

Decision 5: what happens when you change a role

A role change affects everyone holding it, and it is enforced when data is requested rather than by hiding menu items. Reach changes for those users, including on pages they have bookmarked.

Plan role changes like any other change that affects people: know who holds the role before you edit it, and tell them if their access is being reduced.

Decision 6: deleting a role

Deleting a role cannot be undone. Before deleting, move its holders to another role — a user whose role disappears is a support ticket, not a security improvement.

What is expensive to change later

Decision	Cost of changing later
The dashboard type behind a role	Highest. It changes scoping across the whole product for everyone holding it.
Splitting one role into several	High. Every holder must be reassigned, and you have to know which.
Deleting a role in use	High. It cannot be undone and its holders lose their access.
Narrowing permissions on a live role	Medium. Takes effect for holders immediately.
Role name and description	Low.

What happens next

Create the roles you need, then assign them when inviting users or by editing an existing user. Access is enforced on every request, so a role is not a suggestion — it is the boundary.