From cf96ad2c24b2172e393fa652f063336f4ec6290f Mon Sep 17 00:00:00 2001 From: "claude[bot]" <41898282+claude[bot]@users.noreply.github.com> Date: Fri, 10 Apr 2026 17:30:35 +0000 Subject: [PATCH] docs(TSP-1152): add RBAC transition guide and legacy permissions note Add "Transitioning to RBAC" section to enterprise/rbac.mdx covering legacy role mappings, migration process, post-enablement behavior, and admin action items. Add legacy permissions callout to add-members.mdx linking RBAC-enabled orgs to the RBAC docs. Co-Authored-By: Claude Sonnet 4.6 --- admin/project-management/add-members.mdx | 4 ++ enterprise/rbac.mdx | 57 ++++++++++++++++++++++++ 2 files changed, 61 insertions(+) diff --git a/admin/project-management/add-members.mdx b/admin/project-management/add-members.mdx index 7b97675c..8b718db7 100644 --- a/admin/project-management/add-members.mdx +++ b/admin/project-management/add-members.mdx @@ -4,6 +4,10 @@ sidebarTitle: Add members description: "Add members to your project to collaborate with your team." --- + + This page describes the legacy permission system (Admin, Editor, Viewer) used by organizations that have not yet migrated to RBAC. If your organization has RBAC enabled, see [Role-based access controls (RBAC)](/enterprise/rbac) for the current permission model and role definitions. + + ## Add members to your project
diff --git a/enterprise/rbac.mdx b/enterprise/rbac.mdx index 1f147a64..14c4d3e1 100644 --- a/enterprise/rbac.mdx +++ b/enterprise/rbac.mdx @@ -211,6 +211,63 @@ Learn more about [sharing workforces](/build/workforces/share-your-workforce) as ---- +## Transitioning to RBAC + +If your organization is being migrated from legacy permissions to RBAC, this section covers what changes, what stays the same, and what actions you need to take. + +### Before RBAC (legacy permissions) + +The legacy permission system had three roles — Admin, Editor, and Viewer — applied at the project and organization level only: + +- **Admin** — full read and write access to all assets and settings +- **Editor** — read and write access to all datasets, knowledge sets, and agents; could run agents and tools +- **Viewer** — read access to all datasets, knowledge sets, and agents; could run agents + +There was no asset-level granularity. All users with a given role had the same access to every asset in the project by default. Shared credentials (API keys, OAuths) applied project-wide. + +### During the migration + +The Relevance AI team handles the technical migration to RBAC. You do not need to manually migrate roles, but you should review and adjust assignments after migration is complete. + +**How legacy roles map to RBAC roles by default:** + +| Legacy role | Default RBAC role (project level) | +|-------------|-----------------------------------| +| Admin | Admin | +| Editor | Editor | +| Viewer | Viewer | + + + The Viewer role changes significantly under RBAC. Legacy Viewers could run agents — RBAC Viewers cannot run anything and can only view assets they have been explicitly granted access to. Users who only need to interact with agents via chat should be assigned the Chat role, not Viewer. + + +After migration, review every user mapped to Viewer and determine whether they should be: +- **Chat** — for users who only need to use agents through [Relevance Chat](/get-started/chat/introduction) +- **Viewer** — for users who genuinely only need read access to asset configurations and outputs +- **Member** — for users who need to run agents + +### After RBAC is enabled + +Once RBAC is active for your organization: + +- **Asset-level permissions are enforced.** Access to individual agents, tools, and knowledge bases is controlled separately from project-level roles. +- **Project Editors and Admins retain full access** to all assets in that project automatically — project Admin and Editor roles cascade to asset Admin on all assets in the project. +- **Members, Viewers, and Chat users need explicit asset-level permissions.** Without a grant, they will receive a 403 error when attempting to access an asset. +- **Shared credentials can be scoped per tool.** Rather than all project members sharing one set of credentials, asset admins can assign specific authentication accounts per tool. +- **Permissions are assigned via the Share modal** on each individual agent, tool, or knowledge base. + +### Action items for admins + +After RBAC is enabled, complete these steps to restore appropriate access for your team: + +- **Review user roles immediately.** Check that the default role mappings match your intended access levels, particularly for legacy Viewer accounts. +- **Assign asset-level permissions** using the Share modal on each agent, tool, and knowledge base that non-Admin/Editor users need to access. +- **Use RBAC Groups for bulk assignment.** If many users need the same access, create a group and assign asset permissions to the group rather than individual users. +- **Audit chat-only users.** Confirm that users who only need [Relevance Chat](/get-started/chat/introduction) access are assigned the Chat project role, not Viewer. +- **Verify critical users can access required assets.** Test access for key team members, especially those with Member or Viewer roles, before announcing the migration is complete. + +---- + ## Frequently asked questions (FAQs)