For AI agents: a documentation index is available at /llms.txt. A markdown version of this page is available at /guide/cloud/admin/users-and-roles.md.
Users and roles
Manage people, design roles that fit your organisation, and offboard safely.
Every Cloud tier includes unlimited users — access is never a cost decision.
#The default roles
| Role | Scope |
|---|---|
| Admin | Everything: users, billing, settings, every project |
| Manager | Create projects, manage members, approve time |
| Member | Work on tasks in projects they belong to |
| Client / limited | Restricted view for external stakeholders |
Keep admins few
Admins can see every project, change billing and delete data. Two or three is usually right regardless of how senior people are. Admin is a responsibility, not a rank.
#Custom roles
Available from Basic Unlimited. Define exactly what a group can do rather than forcing people into the defaults.
Start from a real problem
Create a role when someone genuinely needs a permission set the defaults do not offer — not to mirror job titles.
Grant the minimum
Start restrictive. Widening when someone hits a wall is a two-minute conversation; unpicking an over-permissioned workspace is a project.
Keep the list short
Fifteen roles nobody can distinguish is worse than four clear ones.
Review it periodically
Roles accumulate permissions. Check what each one can actually do once or twice a year.
#Access is project membership
Roles say what someone can do; project membership says where. A member with full permissions who belongs to no projects sees an empty workspace.
This catches people out constantly when onboarding — the invitation goes out, the person signs in, and there is nothing there.
Tip
On Pro and above, manage membership through teams rather than individually. Far less churn when someone joins, moves or leaves.
#Onboarding
Invite with the right role
Users → Invite.
Add them to projects immediately
In the same sitting.
Assign real work
Two or three tasks waiting on day one teaches more than any tour.
Point them at notification settings
People flooded in week one mute everything permanently.
#Offboarding
The step most often done badly, and the one with real consequences.
Reassign their open tasks first
Tasks stay assigned to a deactivated user and drop out of the team's views. Do this before deactivating.
Check what they owned
Projects, milestones, approval responsibilities, and any integration authorised with their account — integrations tied to a personal account break silently on departure.
Deactivate, don't delete
Deactivating blocks access while keeping their comments, history and logged time attributable. Deleting orphans all of it.
Confirm admin coverage
Never leave the workspace with a single admin, or none.
Deactivation is not instant lockout everywhere
If the person authenticated through SSO, also remove them at the identity provider. Deactivating in one place only is a common gap.
#Auditing access
Review quarterly:
It grows quietly. Trim it.
Cross-check against HR.
Membership accumulates and is rarely removed.
Permissions get added and never taken away.
On Premium, the audit trail records role and membership changes.