Roles and permissions

Roles & access in the Management group shows every role in the project and exactly what it can do.

Editing a built-in role

You are not stuck with the defaults. If your Developers should be able to write client reports, grant the role that permission — no need to promote anyone.

Reset to default puts a role back to what Nalaras ships.

The Owner role cannot be edited. It is what lets you manage roles at all, and weakening it could leave nobody able to undo the change.

Custom roles (Pro)

Create a role from scratch with any combination of permissions, rename built-ins, or hide the ones your team does not use. Hidden roles disappear from the pickers — assignee, waiting-on — but people already holding them keep working.

The bounds

Four rules apply no matter how you configure things:

1. You cannot change your own role.
2. Only an Owner can grant Owner.
3. Only an Owner can change an Owner's role.
4. You cannot grant a permission you do not hold yourself.

These exist because managing a team is not the same as being able to rewrite your own place in it. Without the third rule in particular, someone could promote themselves and then demote the real owner — the project would still have an Owner, just not you.

The audit trail (Pro)

Every role change, member change and permission edit is recorded with who did it, when, and what changed from and to. Audit trail in the Main menu.