Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

🪜Understanding Access Levels

Learn how access scope works (Account, Organization, Project) for assigning the right roles.

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?”

[SCREENSHOT: Role selection dropdown showing current role options]

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.

Option 1: with login access (invited Teammates)

These people will log in to Transform.

1

Choose the right scope

Add them at Account, Organization, or Project.

2

Open Teammates

Go to Teammates at that scope.

3

Add and invite

Enter email. Pick role. Send the invitation.

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.

1

Choose the scope

Add them at the level they should be associated with.

2

Add without inviting

Enter email. Pick role. Keep invitations off.

Email is required. Use an Organization-approved placeholder email when required.

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

1

Open Teammates

Go to the right Account, Organization, or Project.

2

Update the role

Use the row menu. Choose Change role.

[GIF: Changing a teammate's role from View Only to Consultant]

Remove access

1

Remove at the right scope

Removing at the Account level removes access everywhere below it.

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:

Last updated