Governance · Roles & Permissions

Thirty-three permissions, not three seat types.

Admin, Member, and Viewer can't express “this head approves leave for their department only”.

Start free trial Request a demo

Projects

project.createproject.edittask.createtask.edittask.deletedeliverable.createmilestone.approve

Time

timesheet.createtimesheet.submittimesheet.approveattendance.clockattendance.manage

Finance

invoice.requestinvoice.issueinvoice.viewbusiness.view

People

hr.viewemployee.exportleave.requestleave.approveleave.manageperformance.reviewperformance.manage

Recruitment

recruitment.viewrecruitment.managerecruitment.convert

Oversight

report.viewreport.exportaudit.viewapproval.overrideadmin.configurehelpdesk.createhelpdesk.manage

The full catalogue, as it ships — and every key is enforced on the server.

Building a role.

01Start from what the job actually does, not from a tier you're trying to fit someone into.

02Grant the permissions that job needs — a finance reviewer who can approve but not issue is a normal thing to want.

03Scope it by department, so the same role means “their team” for each head who holds it.

04Change it later without migrating anyone between plans or seat types.

The UI is not the boundary

Hiding a button is a courtesy, not a control. Every permission here is checked again on the server, which is why the client can afford to be generous about showing people where things are.

Where this connects.

Approvals & Workflow

One inbox for every approval waiting on you.

People & HR

One employee directory, one source of truth.

Reporting & Dashboards

Dashboards scoped to what each role should actually see.

See Roles & Permissions on your own work.

We'll run a live project of yours through it rather than showing a demo tenant.

Request a demo