> ## Documentation Index > Fetch the complete documentation index at: https://docs-platform.crewai.com/llms.txt > Use this file to discover all available pages before exploring further. # Moving to RBAC v2 > How your roles, permissions, and sharing settings were carried over to RBAC v2, and how the old terms map to the new ones. ## Overview CrewAI moved organizations from the original role system ("legacy RBAC") to [RBAC v2](https://docs-platform.crewai.com/platform/en/features/rbac.md). 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 | Legacy RBAC | RBAC v2 | What changed | | :- | :- | :- | | **Role** (Owner, Member, custom roles) | **Team** | Each legacy role became a team with the same name and the same people. | | **Feature permission** (Manage / Read / No access) | **Role** granted at **Organization** scope | Instead of one level per feature, a team holds specific roles, such as **Automation Creator**. | | **Sharing / visibility / whitelist** on a resource | **Role** granted on **one resource** | Each share became a role on that resource, chosen from its level. | | Permission types `run`, `traces`, `manage_settings`, `full_access` | **Operator**, **Editor**, **Admin** | See [Sharing levels](#sharing-levels). | | **Owner** role and organization owner | **Administrators** team | Owners get full access by being on the Administrators team. | | Assigning a role to a member | Adding a member to a team, or giving them a role | A person can belong to many teams and hold many roles. | | **Settings → Roles** | **Settings → Teams** and **Settings → Members** | The Roles page is closed. Legacy roles no longer control access. | | Custom roles you defined | Custom teams | You can't define new roles. You combine roles from the CrewAI list. | ## 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](#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](#sharing-levels). ### Resources people own People who owned a resource kept full control of it: | What they owned | What they have now | | :- | :- | | An automation | **Automation Admin** on it, and **Automation Creator** | | A Crew Studio project | **Studio Project Admin** on it, and **Studio Project Creator** | | An application connection | **Application Connection Admin** on 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. | Legacy permission | Read | Manage | | :- | :- | :- | | `crews_dashboards` (Automations) | No role. Everyone can open the Automations page, and it lists the automations they have a role on. | Automation Creator | | `studio_projects` | No role | Studio Project Viewer, Studio Project Creator, Automation Creator | | `agents` | Agent Viewer | Agent Admin, Agent Creator | | `tools` | Skill Operator, Application Connection Creator | Tool Creator, Tool Admin on each existing tool, Skill Admin, Skill Creator, Application Connection Creator | | `llm_connections` | No role. Shared connections decide access. | LLM Connection Creator | | `environment_variables` | No role. Shared variables decide access. | Environment Variable Creator | | `agent_control_plane` | Agent Control Plane Viewer, ACP Policy Viewer | Agent Control Plane Viewer, ACP Policy Viewer, ACP Policy Creator, ACP Policy Admin | | `invitations` | No role | Identity and Access Admin | | `organization_settings` | Identity and Access Admin | Organization Admin, Identity and Access Admin, Git Repository Operator, Git Repository Creator, Git Repository Admin | | `default_settings` | No role | Organization Admin | | `usage_dashboards` | No role | Usage and Billing Admin | | `secret_providers` | No role | Identity and Access Admin | | `workload_identity` | No role | Identity and Access Admin | | `training_ui` | No role | No role | > [!NOTE] > > 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 | Legacy share | RBAC v2 role | | :- | :- | | `full_access` | Automation Admin | | `manage_settings` | Automation Editor | | `run`, `human_in_the_loop`, `traces`, or no level | Automation Operator | ### Crew Studio projects | Legacy share | RBAC v2 role | | :- | :- | | `view` | Studio Project Viewer | | `edit` | Studio Project Operator | | `manage` or `full_access` | Studio Project Editor, plus Automation Creator so they can still publish | ### 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. | Resource | Shared with someone who had Manage | Shared with anyone else | | :- | :- | :- | | LLM connection | LLM Connection Admin | LLM Connection Operator | | Environment variable | Environment Variable Admin | Environment Variable Viewer | | Tool | (covered by Tool Admin above) | Tool Operator | | Git repository | Git Repository Operator | Git Repository Operator | ## 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](#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](https://docs-platform.crewai.com/platform/en/features/jit-sso.md) 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. *** > [card] [Need Help?](mailto:support@crewai.com) > > Contact our support team if something looks different from what you expect after the move. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.