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 for day to day role configuration after the switch, see enhanced role based access control (rbac) https //docs swimlane com/enhanced role based access control rbac and enhanced rbac permission reference https //docs swimlane com/enhanced rbac permission reference choose your path goal where to go compare legacy and enhanced rbac what is different /#what is different understand what swimlane changes during migration what happens during migration /#what happens during migration map legacy settings to new permissions how legacy access maps to enhanced rbac /#how legacy access maps to enhanced rbac see which permissions become visible after migration permissions that were hidden and are now visible /#permissions that were hidden and are now visible understand why menus appear or disappear what controls whether a management menu appears /#what controls whether a management menu appears request enhanced rbac or roll back request enhanced rbac /#request enhanced rbac and switch back to legacy /#switch back to legacy 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 https //docs swimlane com/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 when you are ready for enhanced rbac again re migrate the current legacy configuration from scratch, or return to the enhanced rbac configuration that existed when enhanced rbac was switched off support helps you choose based on what changed on each model request enhanced rbac 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) https //docs swimlane com/enhanced role based access control rbac and enhanced rbac permission reference https //docs swimlane com/enhanced rbac permission reference to review and tighten roles 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) https //docs swimlane com/enhanced role based access control rbacenhanced rbac permission reference https //docs swimlane com/enhanced rbac permission reference