# RBAC & Permissions

> Take full control of who can access what — by plan, by role, and by person

Changelog · 2026

## What's New

- Entitlement-driven feature access — what your workspace can see and use is now resolved from your own plan's entitlements rather than a plan label checked in the interface. When your plan changes, your access follows it without waiting on a product update.
- Role-based team permissions — every team member holds a role, and that role decides which modules they can view or edit (Inbox, Reporting, Broadcast, Chatbot, Automation, Integrations, Customers, DataLab, API, Settings). Admins choose which role each member holds; what a role itself permits is configured for your workspace by support.
- Separate read and write controls — permissions are split into read and write, so a team member can have visibility into an area without being able to change anything in it.
- Restricted pages are blocked at the route level — opening a restricted page by direct link or saved URL shows an "Access Restricted" screen instead of loading the page.
- Tailored navigation — the sidebar and the settings menu are assembled from what each person's plan and role actually allow, so unavailable modules are absent rather than shown and blocked.
- Consistent gating inside pages, not just around them — individual panels and controls follow the same access rules, from Inbox panes and Copilot to reporting widgets, integration cards and chatbot builder blocks.
- Billing stays with the workspace creator — the Plan & Billing page is visible only to the creator of the workspace, including for admins with full settings permission.

## Before & After

| ❌ Before | ✅ After |
| --- | --- |
| Feature availability was decided by checking your plan's name in the interface, so changing what a plan includes required a product update. | Feature availability is resolved from your plan's entitlements, so a change to what your plan includes takes effect without an interface change. |
| Restricted pages could be reached by typing or pasting the URL directly, even without permission. | Restricted pages are checked at the route level and show a clear "Access Restricted" screen instead of loading. |
| There was no per-module control over which team members could reach areas like Reporting, Broadcast or Settings sub-pages. | Access is decided per module, and separately for read and for write, through the role each member holds. |
| Everyone on a workspace saw the same navigation regardless of role, with unavailable features shown and then blocked. | Each person's navigation and settings menu is built from their own access, so unavailable modules are simply not there. |
| Access rules stopped at the page boundary — a permitted page showed all of its contents. | Access rules continue inside the page, down to individual panels, widgets, integration cards and builder controls. |

## How to Use It

**For Workspace Admins — Managing Team Access**

1. **Add a team member** — go to **Settings → Team Settings → User Management** and select **+ Add New Member**. The page shows how many seats your plan includes and how many remain.
2. **Set their role** — on the same page, use the **User role** control in that member's row and choose from the roles available on your workspace. The role decides which modules they can reach and whether they can edit within them.
3. **Group members for ticket assignment** — go to **Settings → Team Settings → Group Management** to create a group, add members to it, and turn on **Smart Ticket Assignment** to distribute tickets round-robin to the least engaged agent in that group.

*ℹ️ What each role permits, and any granular permission gating on a group, are configured for your workspace — contact support to change either.*

*ℹ️ Once a change is applied, it takes effect the next time that member's permissions load. If they are signed in, ask them to reload the workspace to pick up the new access.*

**For Team Members — Understanding Your Access**

- When you sign in you see only the modules your plan and role allow. Modules you don't have are absent rather than shown and blocked — that's expected, not a fault.
- Navigation appears once your permissions have loaded. A brief empty sidebar on a slow connection is the permission check completing, not a failure.
- If you open a page you don't have access to — from a saved link, for example — you'll see the screen below. Use **Back to the Dashboard** to return to your workspace.

> **🔒 Access Restricted screen**
>
> **Heading:** Access Restricted
> **Message:** *"It looks like you don't have permission to view this page. This page is restricted to specific roles."*
> **Button:** ← Back to the Dashboard
> **Footer:** Need help? Contact Support

- If you need access to a module you can't reach, contact your workspace admin. They can change the role you hold; if the role itself needs adjusting, they will raise it with support.

**For Workspace Owners — Understanding Plan-Based Access**

- What your workspace can use depends on your plan's entitlements. To see your current plan, go to **Settings → Plan & Billing**.
- The Plan & Billing page is visible only to the workspace creator — other team members, including admins with settings permission, will not see it.
- Some capabilities also depend on the relevant product being enabled for your workspace. The Raven area, for example, appears only when Raven is enabled for you, in addition to the usual plan and role checks.
- If a capability is available on your plan but you want to restrict it for particular people, change the role those people hold rather than changing the plan. If no existing role fits what you need, contact support to have one adjusted for your workspace.

## Summary of Benefits

- Stronger security — access is enforced at the route, not just hidden in the menu, so a saved link cannot be used to reach a restricted page.
- Access that follows your plan — entitlements decide what your workspace can use, so a plan change takes effect without waiting on a product update.
- Precise per-person access — every member's access follows the role they hold, from full rights down to read-only on a single module.
- A cleaner interface — unavailable modules and controls are absent rather than present-and-blocked, at every level from navigation down to individual panels.

## Availability

Role-based permissions and route-level access control are available to every workspace, on all plans.

Which capabilities a workspace can use is determined by its plan's entitlements together with each person's role permissions. To see what your workspace currently includes, open **Settings → Plan & Billing** — visible to the workspace creator.

Plan-level access applies to the workspace; role permissions apply to each person within it. Both are checked, so a capability appears only when the plan includes it and the person's role allows it.

---
HTML: https://userevora.com/docs/changelog/rbac-permissions