Roles & Permissions

Roles control what members can do. TestFlair separates roles into two scopes so you can grant broad workspace access and fine-grained project access independently.

Scope	Controls	Roles
Workspace role	Permissions across the entire workspace, including team management	Owner, Coordinator, Member
Project role	Permissions inside a specific project	Project Admin, QA Manager, Tester, Business Analyst, Developer, Viewer

Every member has exactly one workspace role. Project roles are assigned per project — directly, or inherited from a group assigned to that project.

Workspace Roles

Role	What it can do
Owner	Full workspace control, including billing, member management, and workspace settings. Created automatically for whoever created the workspace.
Coordinator	Manage members, projects, and groups. Cannot manage billing or workspace settings.
Member	Standard member — can view and create projects, but gets no project access automatically.

important

Owner and Coordinator have implicit full access to every project in the workspace. They don't need to be added to a project to work in it, and assigning them a project role changes nothing — their workspace role already grants everything.

Member is the opposite. A Member with no project assignment has no access to any project's contents. They must be added to a project directly or through a group.

Project Roles

Project permissions are built from three bundles:

Bundle	Grants
Manage project members	Add, remove, and re-assign people and groups on the project
Manage requirements	Create, update, and delete user stories, features, project context, test data, and project attachments
Manage testing	Create, update, and delete test cases, scripts, test data, bugs, and bug attachments, and run executions

Each default project role is a combination of those bundles:

Role	Members	Requirements	Testing
Project Admin	✓	✓	✓
QA Manager	—	✓	✓
Tester	—	—	✓
Business Analyst	—	✓	—
Developer	—	—	—
Viewer	—	—	—

Everyone assigned to a project can read it

Anyone with any assignment to a project — direct or via a group — automatically gets read access to all of that project's artifacts, whatever their role. That's why Developer and Viewer show no bundles above but are still useful: they can see everything in the project and change nothing.

The rule only applies to people who are actually assigned. A workspace Member with no assignment to a project sees nothing in it.

Default and Custom Roles

• Default roles are the workspace and project roles listed above. They ship with TestFlair and can't be edited or deleted.
• Custom roles are roles you define yourself with exactly the permissions your team needs. Custom roles are created in the Roles section of the Teams page.

Creating a Custom Role

1. Open Teams and go to the Roles section.
2. Click Create Role.
3. Give the role a name and an optional description.
4. Choose its scope — workspace or project.
5. Choose its permissions. Permissions are organized into groups — toggle a whole group on or off, or pick individual permissions within it.
6. Click Save.

tip

Start from the permission groups to set a baseline quickly, then fine-tune individual permissions for the exceptions you need.

Editing a Custom Role

Select Edit on a custom role to rename it, update its description, or change its permissions. Changes apply to every member who holds that role.

Deleting a Custom Role

Select Delete on a custom role and confirm. Default roles cannot be deleted.

info

Before deleting a role, make sure no members still depend on it — reassign them to another role first so they keep the access they need.

Next Steps

• Manage Members — Assign roles to members
• Groups — Apply roles to many members at once via groups