Custom Roles
Custom Roles let organization admins define exactly what each team member can do within a project. Instead of choosing between the three built-in roles (Developer, Support, Tester), you can create roles tailored to your team’s structure — for example, a QA Lead who triages bugs but doesn’t manage integrations, or a Community Manager who views analytics and moderates suggestions.
System Roles vs Custom Roles
Every project comes with three system roles that cover the most common team profiles:
| System Role | What it covers | Billable? |
|---|---|---|
| Developer | Full access to all project modules and settings | Yes |
| Support | Tickets, bug/suggestion viewing, and basic reporting | No |
| Tester | Submit bugs, suggestions, and tickets; view own or all reports based on project settings | No |
System roles cannot be edited. They serve as a reliable baseline and as starting templates for custom roles.
Custom roles are created at the organization level and can be assigned to members on any project within that organization. Each custom role has a hand-picked set of scopes (permissions) and a persona that controls the UI layout.
Managing Roles
Accessing the Roles Page
- Go to your organization page
- Navigate to Organization → Roles by clicking Manage Roles in the Roles card
You’ll see two sections: System roles (read-only) and Custom roles (editable).
Creating a Custom Role
There are two ways to create a custom role:
Clone a system role (recommended for your first custom role):
- On the Roles page, find the system role closest to what you need
- Click Clone to customize
- The new role form opens with the system role’s scopes pre-selected (read-only preview)
- Give it a name and save
- Open the newly created role and edit its scopes as needed
Create from scratch:
- Click New custom role
- Fill in the name, description, persona, and select scopes
- Save
Editing and Deleting
- Click Edit on any custom role to change its name, persona, or scopes
- Click Delete to remove a custom role — all members assigned this role will lose it
Deleting a custom role immediately removes that role from every project member who holds it. If a member has no other roles, they effectively lose project access until another role is assigned.
Understanding Scopes
Scopes are individual permissions that control what a role can do. When creating or editing a custom role, you pick scopes from a categorized checklist.
Scope Categories
Bugs
| Scope | What it allows |
|---|---|
| Edit bugs (any author) | Change title, description, status, priority, labels on any bug |
| Archive bugs | Archive and unarchive bugs |
| Mark duplicates | Mark and unmark duplicates, merge bugs |
| Convert bugs | Convert a bug to a suggestion or support ticket |
| Request details | Ask the reporter for screenshots, logs, or clarification |
| Bulk update | Update multiple bugs at once |
| Delete bugs | Delete bugs (with a reason) |
| Push to integrations | Send bugs to external tools (Jira, GitHub, etc.) |
| Public share links | Generate or revoke public share links for individual bugs |
| Clarify | Run the LLM clarify action on bugs |
Suggestions
| Scope | What it allows |
|---|---|
| Edit suggestions | Edit, merge, split, detach, or delete suggestions |
| Moderate suggestions | Approve, reject, mute, or restore suggestions in the moderation queue |
Tickets
| Scope | What it allows |
|---|---|
| View tickets | View support tickets (read-only) |
| Edit tickets | Edit support tickets |
Analytics
| Scope | What it allows |
|---|---|
| View analytics | View sentiments, statistics, and download stats |
Integrations
| Scope | What it allows |
|---|---|
| View integrations | View connected integrations and Discord bot config |
| Manage integrations | Connect and disconnect external integrations |
| Manage API tokens | Manage API tokens for the project |
| Manage webhooks | Manage outgoing webhooks |
Members
| Scope | What it allows |
|---|---|
| Manage members | Invite, remove, and assign roles for project members |
| Review access requests | Accept or reject incoming project access requests |
Releases
| Scope | What it allows |
|---|---|
| Manage releases | Create and edit releases |
Project Configuration
| Scope | What it allows |
|---|---|
| Edit settings | Edit general project settings |
| Manage taxonomy | Manage issue statuses, tags, groups, custom fields, and log redaction patterns |
| Manage support | Manage support canned responses and knowledge base |
| Manage automation | Manage automation rules and tasks |
| Manage surveys | Manage project surveys |
| View guidelines | View AI guidelines (read-only) |
| View key collections | View game key collections (read-only) |
| Manage NDA | Manage NDA versions and signer enforcement |
| Manage boards | Manage public bug and feature request boards |
| Manage notifications | Edit project-wide notification defaults |
Administration
| Scope | What it allows |
|---|---|
| Manage roles | Create and edit custom roles inside the organization |
Comments
| Scope | What it allows |
|---|---|
| Moderate comments | Mark comments as public/private or as a solution |
You don’t need to memorize these scopes. The role form shows every scope with a short description, grouped by category.
Persona
Every role — system or custom — has a persona that controls the user interface layout:
| Persona | UI behavior |
|---|---|
| Developer | Technical bug-board view with full detail columns, triage tools, and settings access |
| Tester | Simpler submitter view focused on reporting and viewing feedback |
| Support | Support-oriented view with ticket management tools |
The persona is purely cosmetic. It determines which version of the interface a member sees, but it does not grant or restrict any permissions. Permissions come only from scopes.
For example, a custom role with developer persona and only the “View analytics” scope would see the developer-style navigation, but could only access the analytics dashboard.
When a member holds multiple roles with different personas, the highest-privilege persona wins: Developer > Support > Tester.
Billing and Seat Impact
Custom roles affect billing depending on which scopes they include.
How it works:
- The system Support and Tester roles define a “non-seat baseline” — the set of scopes that don’t trigger billing
- If a custom role includes any scope outside that baseline, every member assigned this role counts as a billable developer seat
- Scopes that trigger a seat are marked with an asterisk (*) in the role form
In practice, most scopes that go beyond basic reporting and ticket handling will trigger a seat. The exact set depends on what the system Tester and Support roles include.
A seat warning banner appears below the scope list whenever your selection would make the role seat-consuming:
* This role will consume a billable seat for every member assigned. Scopes marked with * are the reason. Tester-level scopes (reporting, ticket replies) don’t trigger seat status on their own.
If you edit an existing non-seat role and add seat-triggering scopes, all current holders of that role will be automatically promoted to billable developer seats on the organization. The change is reflected on your next billing cycle.
Assigning Roles to Members
Once you’ve created custom roles, you can assign them to project members.
On the Member Edit Page
- Navigate to your project’s Members page
- Click the Edit button next to a member
- You’ll see their current roles as badges — click the remove button on any badge to remove it (a confirmation dialog will ask you to confirm)
- Use the Add a role dropdown to assign additional roles (both system and custom roles appear here)
- Click Add role
Multiple Roles
A member can hold multiple roles simultaneously. Their effective permissions are the union of all scopes from all assigned roles. For example:
- A member with both Tester and a custom “Analytics Viewer” role can submit bugs (from Tester) and view sentiment dashboards (from the custom role)
- A member with a custom “QA Lead” role and the system Support role gets both bug management scopes and ticket access
Example Custom Roles
Here are some custom role ideas to get started:
QA Lead
A senior tester who triages bugs but doesn’t manage project settings.
| Setting | Value |
|---|---|
| Persona | Developer |
| Key scopes | Edit bugs, Archive bugs, Mark duplicates, Bulk update, Request details, View analytics |
| Billable? | Yes (bug management scopes exceed the baseline) |
Community Manager
Handles suggestions and views analytics to understand player sentiment, but doesn’t touch bugs or settings.
| Setting | Value |
|---|---|
| Persona | Developer |
| Key scopes | Edit suggestions, Moderate suggestions, View analytics, View integrations |
| Billable? | Yes |
Support Specialist
Extends the built-in Support role with the ability to view integrations and analytics.
| Setting | Value |
|---|---|
| Persona | Support |
| Key scopes | View tickets, Edit tickets, View analytics, View integrations |
| Billable? | Yes (View analytics exceeds the baseline) |
External Auditor
Read-only access to tickets and analytics, useful for compliance reviews.
| Setting | Value |
|---|---|
| Persona | Tester |
| Key scopes | View tickets, View analytics |
| Billable? | Yes (View analytics exceeds the baseline) |
FAQ
Q: Can I edit the built-in system roles? A: No. System roles are read-only to keep them consistent across all organizations. Use Clone to customize to create an editable copy with the same scopes, then adjust it.
Q: What happens when I delete a custom role? A: All members who hold that role lose it immediately. If they have no other roles on the project, they effectively lose access. Make sure to reassign members before deleting.
Q: Will creating a custom role increase my bill? A: Only if the role includes scopes that go beyond the Tester + Support baseline. The role form shows an asterisk (*) next to seat-triggering scopes and a warning banner when your selection would make the role billable.
Q: Can a member have both a system role and a custom role? A: Yes. A member can hold any combination of system and custom roles. Their effective permissions are the sum of all roles’ scopes.
Q: Where do I create custom roles — on the project or the organization? A: Roles are created at the organization level (Organization → Roles), but assigned at the project level (Project → Members → Edit member). This means one custom role can be used across all projects in the organization.
Q: What does “persona” do if it doesn’t affect permissions? A: The persona controls which UI layout the member sees. A Developer persona shows the full technical interface (detailed bug tables, triage tools, settings navigation), while a Tester persona shows a simpler view focused on submitting and viewing feedback.
See Also
- Organizations – Team and billing management
- Project Setup – Create projects and invite members
- Project Settings – Configure project options and permissions
- Security – Authentication and access control