> 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/understanding-access-levels.md).
# Understanding Access Levels
### Overview
Access levels define what a Teammate can see and do. Access is assigned by scope, then constrained by role.
### Key Concepts
* **Scope**: visibility boundary (Account, Organization, Project)
* **Role**: permission set within a scope
* **Mixed membership**: different roles for the same Teammate across scopes
### How It’s Used
Use scope to limit what is visible. Use roles to limit what actions are permitted.
### Benefits
* Clear visibility boundaries
* Reduced risk from over-scoped access
* Cleaner governance through predictable admin assignment
### Setup Steps
#### Access scope (Account, Organization, Project)
#### Account level
Account access is the broadest scope.
It spans every Organization and Project.
**Good fit for**
* System admins
* Leaders who need global visibility
* People managing multiple Organizations
**What they can do**
* See all Organizations and Projects
* Manage Account settings
* Add or remove Teammates anywhere
**Example**
For example: a transformation office leader needs visibility across all Organizations.
#### Organization level
Organization access is a department or business unit scope.
It includes every Project inside that Organization.
**Good fit for**
* Department heads
* Team leads for one division
* Consultants working in one area
**What they can do**
* See all Projects in the Organization
* Manage Teammates in the Organization
* Cannot see other Organizations by default
**Example**
For example: a department lead needs visibility for one Organization only.
#### Project level
Project access is the narrowest scope.
It limits someone to a single initiative.
**Good fit for**
* Project team members
* External stakeholders
* Anyone who should only see one project
**What they can do**
* Work inside that Project
* Cannot see other Projects in the Organization
**Example**
For example: a workstream contributor needs visibility for one Project only.
#### Roles at any scope
Role answers one question.
“What can they do there?”
{% hint style="info" %}
\[SCREENSHOT: Role selection dropdown showing current role options]
{% endhint %}
Role names vary by Account configuration. Common patterns include:
* **Owner**: Hold broad control within the assigned scope, such as a Project or Organization. Edit, delete, assign, and manage work in that scope.
* **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.
* **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.
#### Account-level global roles
These roles apply across the full Account.
* **Account Administrator**: global permission to everything. Cannot be archived, hidden, or deleted.
* **Managing Partner**: global permission to everything. Applies across all Organizations and all Projects, including external access.
#### Organization-scoped delivery roles
These roles apply across all Projects within assigned Organizations.
* **Project Manager**: Project administration scoped to assigned Organizations.
* **Consultant**: full permissions scoped to assigned Organizations.
#### Client-facing roles
These roles are used for client or external participants.
* **Client Collaborator**: edit access on assigned Organizations and Projects.
* **Client Tester**: edit access on Test Cases only. View-only on everything else.
Enable **External** when assigning either client-facing role.
#### Explicit read-only role
* **View Only**: read-only access wherever explicitly added. No Organization-wide or Project-wide access by default.
#### Mixed membership
One person can have different roles in different places.
This is called **mixed membership**.
**Example**
For example: one Teammate can be an Account Admin, an Organization Member, and a Project Viewer.
For example: one Teammate can be a **Managing Partner** across the Account and **View Only** on a specific client-facing area.
Why it matters:
* Least-privilege access is possible without blocking delivery work.
* Stakeholders can be kept read-only.
* Duplicate Teammate records are avoided.
#### Add Teammates
For the full flow, see [Add Teammates](/organizations-and-projects/add-teammates.md).
**Option 1: with login access (invited Teammates)**
These people will log in to Transform.
{% stepper %}
{% step %}
### Choose the right scope
Add them at Account, Organization, or Project.
{% endstep %}
{% step %}
### Open Teammates
Go to **Teammates** at that scope.
{% endstep %}
{% step %}
### Add and invite
Enter email. Pick role. Send the invitation.
{% endstep %}
{% endstepper %}
After an invitation is sent:
* An email invitation is delivered.
* The Teammate accepts and signs in.
* The Teammate appears in the Teammates list.
**Option 2: without login access (stakeholders or contacts)**
These people are tracked. They do not log in.
{% stepper %}
{% step %}
### Choose the scope
Add them at the level they should be associated with.
{% endstep %}
{% step %}
### Add without inviting
Enter email. Pick role. Keep invitations off.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Email is required. Use an Organization-approved placeholder email when required.
{% endhint %}
#### Picking the right access level
Start with scope. Then pick a role.
* Visibility across all departments → **Account**
* Visibility for one department → **Organization**
* Visibility for one initiative → **Project**
Then choose a role:
* Manage Account-wide access and settings → **Account Administrator**
* Manage Project delivery, assignments, and workflows → **Project Manager** or **Owner**
* Create and edit delivery work → **Consultant** or **Member**
* Review shared work or execute tests with limited edit rights → **Client Collaborator** or **Client Tester**
* Read-only visibility → **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 → **Client Collaborator**
* Client-facing test execution → **Client Tester**
* Read-only visibility → **View Only**
#### Common setups
#### Consulting firm with multiple clients
* Account: delivery organization
* Organization: each client
* Project: each engagement
Typical access:
* Consultants: Project access with **Consultant** or **Project Manager**
* Client sponsors: Organization access with **Client Collaborator** or **Viewer**
* Leadership: Account access with **Account Administrator** or **Viewer**
* Consultants: **Consultant** or **Project Manager**, based on responsibility
* Partners: **Managing Partner**
* Leadership: **Account Administrator** or **Managing Partner**
#### Large enterprise transformation
* Account: the enterprise
* Organization: IT, Finance, Ops, HR
* Project: each initiative
Typical access:
* Department heads: Organization access with **Owner** or **Viewer**
* Project managers: Project access with **Project Manager**
* Transformation office: Account access with **Account Administrator**
#### Small company transformation
* Account: the company
* Organization: one default org
* Project: workstreams
Typical access:
* Leadership: Account access with **Account Administrator** or **Owner**
* Team members: Project access with **Member** or **Consultant**
* Leadership: **Account Administrator** or **Managing Partner**
* Team members: **Consultant** or **View Only**
#### Managing access over time
**Change a Teammate role**
{% stepper %}
{% step %}
### Open Teammates
Go to the right Account, Organization, or Project.
{% endstep %}
{% step %}
### Update the role
Use the row menu. Choose **Change role**.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
\[GIF: Changing a teammate's role from View Only to Consultant]
{% endhint %}
**Remove access**
{% stepper %}
{% step %}
### Remove at the right scope
Removing at the Account level removes access everywhere below it.
{% endstep %}
{% endstepper %}
#### Review access regularly
Do this monthly. Do this after major delivery milestones.
Look for:
* Contractors who rolled off
* Stakeholders who only need **View Only**
* People with broad access who no longer need it
### Best Practices
* Start with the least access that supports delivery needs.
* Enable **External** for client-facing roles.
* Limit **Account Administrator** and **Managing Partner** access to a small set of leaders.
* Keep roles updated as people change responsibilities.
### Troubleshooting
Project access is missing
* Confirm the correct Organization is selected.
* Ask an Admin to add access at Project or Organization scope.
* Check whether the Project was archived.
Someone has too much access
* Reduce scope first (Account → Organization → Project).
* Then reduce role to a narrower option, such as **Managing Partner** → **Project Manager** → **Consultant** → **View Only**.
Many Teammates must be added
* Add them individually.
* Use a standard onboarding checklist.
* Keep roles consistent by team.
Multiple emails across scopes
Each Teammate record uses a single email address across the Account.
### Summary
Access is assigned at Account, Organization, or Project scope.
Roles constrain actions within the selected scope.
Mixed membership supports least privilege across multiple initiatives.
Related:
* [Add Teammates](/organizations-and-projects/add-teammates.md)
* [User Roles and Permissions](/organizations-and-projects/user-roles-and-permissions.md)
* [Organization Settings and Management](/organizations-and-projects/organization-settings-and-management.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/understanding-access-levels.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.