Move from Legacy RBAC to Enhanced RBAC
If your account was created before Enhanced RBAC became generally available, it stays on the legacy access model until Swimlane enables Enhanced RBAC for you. This topic explains what changes, what happens to existing roles and users, and how to request the switch.
On Turbine Platform on-premises, version 26.4 or later, a Super Admin enables Enhanced RBAC with Enable Enhanced RBAC on the Turbine Platform (On-Prem).
For day-to-day role configuration after the switch, see Enhanced Role-Based Access Control (RBAC)Enhanced Role-Based Access Control (RBAC) and Enhanced RBAC Permission Reference.
Choose Your Path
Goal | Where to go |
|---|---|
Compare legacy and Enhanced RBAC | |
Understand what Swimlane changes during migration | |
Map legacy settings to new permissions | |
See which permissions become visible after migration | |
Understand why menus appear or disappear | |
Request Enhanced RBAC or roll back | |
Enable Enhanced RBAC on Turbine Platform on-premises |
What Is Different
Legacy RBAC was narrow. You could configure permissions for only six resource types β Workspaces, Dashboards, Applications, Applets, Records, and Reports. Everything needed to build Turbine automations (playbooks, components, connectors, assets, events, and so on) sat behind a single role toggle, Grant access to all Turbine Elements. Turning it on gave the role create, read, update, and delete on all of those orchestration resources at once and hid the per-resource permission tabs. A separate user-level setting, Account Admin, overrode roles and gave unrestricted access to all data in every tenant. Each legacy role belonged to exactly one tenant.
A side effect: Account Admin users and any role with Grant access to all Turbine Elements bypassed record locking, record restrictions, and field restrictions. Anyone who needed to build automations was also powerful enough to read and change restricted records and fields.
Enhanced RBAC replaces this with granular permissions:
Area | Enhanced RBAC behavior |
|---|---|
Resources and access types | More resources and access types are configurable on a role, including access that legacy granted silently. |
Orchestration | Playbooks & Components, Assets, Connectors, Events, Webhooks, Pools, and Remote Agents are separate permissions. |
Account Admin | Shipped as a role you can copy and trim, not a user flag. |
Locking and restrictions | Ordinary resource permissions you can grant or remove on any role. |
Role scope | Roles are account-level. One role can carry permissions for several tenants and grant different access in each. |
What Happens During Migration
Migration is handled by the Swimlane team. You do not need to reconfigure roles yourself for the switch.
During the switch | Result |
|---|---|
Existing roles | Recreated in the new system with permissions that match prior access. |
Account Admin users | An Account Admin role is created and assigned to every user who had the Account Admin setting. |
Users and groups | Keep the same roles they held in legacy. |
Legacy configuration | Kept as it was so the account can return to legacy RBAC if a blocking problem appears. |
When migration finishes, the account uses Enhanced RBAC only. There is no preview or mixed mode.
How Legacy Access Maps to Enhanced RBAC
Legacy role setting | Enhanced RBAC equivalent |
|---|---|
Workspaces | Workspaces β Create, Read, Update, Delete |
Dashboards | Dashboards β personal dashboards use explicit Create Personal |
Applications | Applications β same actions |
Applets | Applets β same actions |
Records (Create, Read, Update, Delete, Lock, Restrict) | Application Records β same actions, plus Override Locks, Workflow History, Bypass Restrictions, and Moderate Comments as explicit access types |
Reports | Reports β personal reports use explicit Create Personal |
Grant access to all Turbine Elements | Full access across tenant resources, expressed as separate adjustable permissions (Playbooks & Components, Assets, Connectors, Events, Webhooks, Pools, Remote Agents, and the resources above) |
Account Admin (user setting) | The Account Admin role, assigned to the same users |
Permissions That Were Hidden and Are Now Visible
Legacy RBAC granted several permissions silently so common actions worked. For example, every role could read Turbine elements so analysts could run playbooks from record buttons. You could not see or change that access. Enhanced RBAC still grants it during migration, but it appears on the role and can be adjusted.
Migration adds these read-level permissions to existing roles (they were always in effect, just invisible):
- Tenant β Read β enter a tenant and reach its data
- Playbooks & Components β Read, Execute, Run Details β playbook buttons on records keep working
- Assets, Connectors, Events, Webhooks, Pools, Remote Agents β Read β read visibility across orchestration resources
- Users β Read and Groups β Read (account level) β people and groups remain selectable in admin lists, pickers, and user/group fields
You can review or reduce these after migration. See Enhanced RBAC Permission Reference.
What Controls Whether a Management Menu Appears
Read-level access lets a user use a resource. Higher access reveals screens for managing it.
Area | When the management UI appears |
|---|---|
Orchestration editors (Playbooks and Components lists) | Create, Update, or Delete on playbooks. Read-only users can still run playbooks from a record button. |
Connectors and Assets management | Create, Update, or Delete on playbooks, plus Read on the connector or asset |
Operational Health (Events, Playbook Alerts) | Create, Update, or Delete on Playbooks, plus Events β Read or Playbook Alerts β Read |
Playbook Runs | Playbooks & Components β Run Details (read-level exception) |
Tenant management (Applications & Applets, Workspaces, Dashboards, Reports) | Create, Update, or Delete on those resources |
Admin and settings screens | Admin Panel β Read plus Read on the page's resource |
Everyday work needs Read (and Execute). Screens for building and managing a resource open with Create, Update, or Delete. Playbook Runs and some Usage dashboards open with read-level actions such as Run Details or Events β Read. Migration sets levels to match prior access, so menus after the switch should match what users saw in legacy.
Switch Back to Legacy
If a blocking issue appears, Swimlane can move the account back to legacy RBAC. The account returns to the exact role configuration it had at migration. Changes made on the Enhanced RBAC side after migration are not copied back.
On Turbine Platform, roll back with Roll Back to Legacy RBAC.
When you are ready for Enhanced RBAC again:
- Re-migrate the current legacy configuration from scratch. On Turbine Platform, use Re-Migrate and Switch On Again.
- Return to the Enhanced RBAC configuration that existed when Enhanced RBAC was switched off. On Turbine Platform, use Turn Enhanced RBAC Back On.
On Turbine Cloud, Support helps you choose based on what changed on each model.
Request Enhanced RBAC
On Turbine Cloud, request the switch through Support.
- Raise a support request to enable Enhanced RBAC for your account.
- Agree a date and time for the switch with the support team.
- After the switch, use Enhanced Role-Based Access Control (RBAC)Enhanced Role-Based Access Control (RBAC) and Enhanced RBAC Permission Reference to review and tighten roles.
On Turbine Platform on-premises, version 26.4 or later, follow Enable Enhanced RBAC on the Turbine Platform (On-Prem).
If a problem appears after the switch, support can help resolve it or coordinate a move back to legacy RBAC if a fix would take longer than acceptable.
Next Steps
- Enhanced Role-Based Access Control (RBAC)Enhanced Role-Based Access Control (RBAC)
- Enable Enhanced RBAC on the Turbine Platform (On-Prem) β self-serve enablement for Turbine Platform on-premises, version 26.4 or later