Skip to main content

Overview

CrewAI moved organizations from the original role system (“legacy RBAC”) to RBAC v2. This page explains what your account looks like after the move, how the old terms map to the new ones, and what to check once your organization is on RBAC v2. The goal of the move was to keep everyone’s access as close to what it was as possible. Your legacy roles and sharing settings were turned into teams and grants. Nobody had to set anything up again.

Old terms, new terms

What your account looks like after the move

The Administrators team

Everyone who was an organization owner, or had the legacy Owner role, is on the CrewAI-managed Administrators team. This team has full access to everything in the organization. Owners no longer get access just from being the owner. If you remove someone from the Administrators team, they lose full access.

One team for each legacy role

Each legacy role (other than Owner) became a custom team:
  • The team has the same name as the role, for example Member, Developer, or Support.
  • The team has the same people as the role. People who had no role were treated as Member, so they are on the Member team.
  • The role’s feature permissions became roles held by the team. See Feature permissions.
  • Anything shared with the role was shared with the team.
These are regular custom teams. You can rename them, change their members and roles, or retire them.

Sharing

Every share carried over:
  • A resource shared with a person is now a role for that person on that resource.
  • A resource shared with a legacy role is now a role for that role’s team on that resource.
The role was picked from the share’s level. See Sharing levels.

Resources people own

People who owned a resource kept full control of it: From now on, whoever creates a resource automatically becomes its Admin.

Service accounts

Service accounts had no legacy role, so they did not join a team. They received:
  • Automation Admin on each automation they own.
  • Application Connection Admin on each application connection they own.
  • Studio Project Admin at Organization scope, so they can still delete Studio projects through the API.

Feature permissions

This table shows the roles each legacy feature permission gave the role’s team. All of them are at Organization scope unless noted.
If your organization did not turn on the Git repositories RBAC setting, teams whose legacy role could create automations (crews_dashboards Manage or studio_projects Manage) also got Git Repository Operator, so they can still pick a repository when they deploy.

What the default Member team holds

The default legacy Member role became the Member team. Unless you changed the Member role before the move, the Member team holds:
  • Studio Project Viewer, Studio Project Creator, and Automation Creator
  • Agent Viewer
  • Skill Operator and Application Connection Creator
  • Agent Control Plane Viewer and ACP Policy Viewer
  • Git Repository Operator, if the Git repositories RBAC setting was off
  • A role on each resource that was shared with the Member role, such as organization environment variables

Sharing levels

Each share became one role on that resource. When a share had more than one level, the highest level was used.

Automations

Crew Studio projects

Other resources

Legacy shares for these resources had no level. The new role depends on the legacy level of the person or role the resource was shared with.

What works differently now

Most people keep the same access. These are the differences you are most likely to notice.

People gain access

  • Everyone on the Member team can open every Studio project in the organization, because the Member role had Studio Manage. Before, members only saw their own projects and projects shared with them. Opening a project is read-only: running or editing it still needs a higher role on that project.
  • Automation shares are simpler. There is no view-only automation role, so anyone with a share on an automation can now run it, see its traces, and answer human-in-the-loop requests.
  • Settings are no longer owner-only. Billing, Integrations, Theme, and member management used to need an owner. Now anyone with Usage and Billing Admin, Organization Admin, or Identity and Access Admin can open them.
  • Shared LLM connections and environment variables are visible. People with a share can see the connection or variable on its settings page. Environment Variable Viewer can reveal the variable’s value.

People lose access

  • Read-only access to some settings ended. Read on usage_dashboards, secret_providers, default_settings, and workload_identity gave no role. To restore it, give the person or team the matching role from the Feature permissions table.
  • Using an automation’s chat and kickoff screens needs a role on it. Before, any member could start a run, check its status, or use memory from an automation’s Crew UI without a share. Now this needs at least Automation Operator on that automation.
  • Operators can’t see automation environment variable values or delete executions. Seeing environment variable values needs Automation Editor or Automation Admin. Deleting executions needs Automation Admin.
  • Editors can’t share or delete an automation. Someone who had manage_settings without full_access is now an Automation Editor. Sharing and deleting need Automation Admin.
  • Shared application connections are visible only to their owner and the Administrators team, until someone shares them from the connection’s Share button.
  • Service accounts and the people API. API calls that invite users, remove users, or change their roles need the Identity and Access Admin role. Give it to any service account that uses those endpoints.

Managing access works differently

  • The Roles page is closed. Legacy roles no longer control access, so changing them would have no effect. Use Settings → Teams and Settings → Members.
  • Invitations don’t set a role. New people join with no access. Add them to a team after they accept the invitation, or map an SSO group to a team so it happens automatically.

After the move: a checklist

1

Check the Administrators team

Go to Settings → Teams and open Administrators. Make sure only people who should have full access are on it.
2

Review the teams made from your roles

Each legacy role is now a team with the same name. Check its members and roles. Rename teams if a clearer name helps, and retire teams you no longer need.
3

Decide who should see every Studio project

The Member team can open every Studio project. If that is too broad, remove Studio Project Viewer from the Member team and share projects with the people who need them.
4

Plan how new people get access

New members start with no access. Decide which team new people join, and add them after they accept the invitation. With SSO, set up group mappings instead.
5

Check your service accounts

In Settings → Service Accounts, give Identity and Access Admin to any service account that invites or manages users through the API.
6

Restore read-only settings access if needed

If someone relied on read access to usage, secret providers, Crew Studio defaults, or workload identity, give them the matching organization role.

Need Help?

Contact our support team if something looks different from what you expect after the move.