User Roles and Permissions
Understand roles, permissions, and how they apply at Account, Organization, and Project scope.
Overview
Roles define what actions are permitted within a scope. Scopes define what content is visible.
Use Understanding Access Levels to pick scope first.
Key Concepts
Scope: Account, Organization, Project visibility boundary
Role: permission set within a scope
Mixed membership: different roles for the same Teammate at different scopes
How It’s Used
Use roles to separate governance actions from delivery actions. Assign roles per scope to match the delivery model.
Benefits
Fewer permission mistakes
Reduced risk from over-scoped access
Cleaner governance through predictable ownership
Setup Steps
Account Administrator: Full administrative control across the Account. Manage Teammates, roles, billing, custom fields, and global settings.
Project Manager: Manage work at Project scope. Create and update Projects, assign tasks, manage timelines, configure workflows, and invite Teammates to specific Projects. No Account-wide admin access.
Consultant: Contribute to delivery work without sensitive admin access. Edit entities, such as requirements and solutions, and collaborate inside assigned Projects.
Client Collaborator: Support shared delivery with limited access. View and make limited edits to shared Projects, Artifacts, and discussions without broader internal access.
Client Tester: Focus on testing activity. View test cases, execute tests, and provide feedback without changing core Project structure.
Owner: Hold broad control within the assigned scope, such as a Project or Organization. Edit, delete, assign, and manage work in that scope.
Member: Handle day-to-day delivery work. Create, edit, and view assigned Projects, tasks, and entities without managing Teammates or structural settings.
Viewer: Review work in read-only mode. View Projects, reports, dashboards, and entity details without creating or editing content.
Current roles
Start with scope first. Then assign the narrowest role that supports the work.
Account Administrator: global permission to everything. Cannot be archived, hidden, or deleted. Applies across all Organizations and all Projects.
Managing Partner: global permission to everything. Applies across all Organizations and all Projects, including external access.
Project Manager: Project administration scoped to assigned Organizations. Applies across all Projects within those Organizations.
Consultant: full permissions scoped to assigned Organizations. Applies across all Projects within those Organizations.
Client Collaborator: edit access on assigned Organizations and Projects. Enable External when assigning this role.
Client Tester: edit access on Test Cases only. View-only on everything else. Enable External when assigning this role.
View Only: read-only access wherever explicitly added. No Organization-wide or Project-wide access by default.
The External toggle distinguishes client-facing roles from internal roles. Enable it for Client Collaborator and Client Tester, and for any Teammate who is a client or external user.
Common permission boundaries
Use this as a decision check:
Manage Account-wide access and settings → Account Administrator
Manage Project delivery, assignments, and workflows → Project Manager or Owner
Create and update delivery work → Consultant or Member
Review shared work or execute tests with limited edit rights → Client Collaborator or Client Tester
Review and approve without edits → Viewer
Global administration across the account → Account Administrator or Managing Partner
Project administration across assigned Organizations → Project Manager
Delivery work across assigned Organizations → Consultant
Client-facing editing in assigned areas → Client Collaborator
Client-facing test execution with limited edit rights → Client Tester
Read-only participation → View Only
Best Practices
Keep Account Administrator and Managing Partner access limited.
Enable External for all client-facing Teammates.
Use View Only for stakeholders who only need visibility.
Avoid role sprawl by standardizing role definitions in an internal SOP.
Summary
Roles define permitted actions within a scope. Select scope first. Then assign the least-privilege role.
Related:
Last updated