Roles
Create named permission bundles ("Editor", "Billing Admin", "Support") and assign them to team members.
By the end of this page, you'll have custom roles defined for your team and will be able to assign them to members on invitation or later.
Roles live at Settings → Roles (URL: /settings/roles). A role is simply a name plus a set of permissions that apply inside a particular team.
Why roles (instead of per-member permissions)?
Roles let you solve "what can this kind of person do?" once, then apply it many times:
- Invite five community managers? Pick the same Community Manager role from the dropdown each time.
- Later decide they need one extra permission? Update the role — every member assigned to it picks up the change instantly.
- No need to remember "wait, does Sarah have access to delete plans?" — the role carries the answer.
The role you start with
Every team automatically has a default role called member. It's the role we preselect when you invite someone. You can leave it as-is or redefine its permission list to match what a baseline member on your team should see.
Create a new role
Open Roles Settings.
Go to Settings → Roles (URL: /settings/roles). The page shows all roles for your current team.
Switch team if needed.
If you have multiple teams, confirm the team dropdown at the top is showing the team you want to add the role to.
Click Create role.
A modal appears for the new role's details.
Fill in the role fields.
- Name — A human-readable label, e.g. "Community Manager". Up to 255 characters.
- Code — A machine-friendly identifier, e.g.
community-manager. Letters, numbers, dashes, and underscores only (we enforcealpha_dash). Must be unique within the team. - Description (optional) — A short note to yourself or future collaborators: "Handles day-to-day member questions; no billing access." Up to 255 characters.
- Permissions — Tick the permissions this role should grant. See the permission picker below.
Click Save in the modal.
The role appears in your team's role list. A toast confirms: "Role created successfully." You can now assign it to new and existing team members.
The permission picker
When creating or editing a role, the permissions section shows every permission grouped by entity (the thing the permission acts on). You'll see 7 groups, each with the same 5 actions:
| Entity group | Actions available |
|---|---|
| project | view-any, view, create, update, delete |
| project-payment-method | view-any, view, create, update, delete |
| project-resource | view-any, view, create, update, delete |
| project-access-code | view-any, view, create, update, delete |
| project-subscription | view-any, view, create, update, delete |
| project-subscription-plan | view-any, view, create, update, delete |
| project-user | view-any, view, create, update, delete |
That's a total of 35 individual permissions. See Ability reference for the full table with plain-English descriptions.
Shortcut: toggle whole groups
Next to each group's heading is a toggle that selects or deselects every action in that group at once. Use it when you want a role that, say, can do everything related to access codes but nothing else — one click and you're done.
Shortcut: select all
There's also a Select all toggle at the top of the picker for super-admin-like roles. Use sparingly — the whole point of roles is least-privilege.
Edit an existing role
On the Roles page, find the role and click its Edit (pencil) icon.
Change the name, description, or tick/untick permissions. The code is set at creation and remains fixed — it's the stable identifier for that role.
Click Save.
A toast confirms: "Role updated successfully." Team members assigned to this role pick up the changes on their next page load.
Delete a role
On the Roles page, click Delete next to the role.
The role is removed. A toast confirms: "Role deleted successfully."
Only the role's creator or the team owner can delete a role. Members without delete rights will see "You can only delete roles you created."
Deleting a role that's currently assigned to members leaves those members without a defined role — re-assign them to a different role before deleting to avoid confusion.
Roles vs. groups — when to use which
Both give you permission management, but they're best at different jobs:
| Use roles when... | Use groups when... |
|---|---|
| The permission set is tied to a job description (Editor, Finance, Support). | You need ad-hoc access for a one-off project, sprint, or event. |
| You want the same setup applied across many members. | You want to pool permissions for a specific set of people who don't fit an existing role. |
| Member-to-role is 1:1 (one role per person). | Member-to-group can be many-to-many. |
If you're unsure, start with roles. Groups are a refinement for when roles alone feel too rigid. See Groups for the details.
Common questions
Next up
- Groups — when roles aren't the right granularity.
- Ability reference — plain-English descriptions of every permission.
- Invite members — apply your new role when you invite someone.