> For the complete documentation index, see [llms.txt](https://help.transform.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.transform.ai/organizations-and-projects/user-roles-and-permissions.md). # User Roles and Permissions ### Overview Roles define what actions are permitted within a scope. Scopes define what content is visible. Use [Understanding Access Levels](/organizations-and-projects/understanding-access-levels.md) 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. {% hint style="warning" %} 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. {% endhint %} #### 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: * [Add Teammates](/organizations-and-projects/add-teammates.md) * [Understanding Access Levels](/organizations-and-projects/understanding-access-levels.md) * [Project Settings and Configuration](/organizations-and-projects/project-settings-and-configuration.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.transform.ai/organizations-and-projects/user-roles-and-permissions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.