Role-Based Access Control (RBAC)

Technical reference for Unidy's RBAC system: scopes, permission resources, predefined roles, API enforcement and configuration.

Overview

Unidy supports role-based access control (RBAC), allowing tenant administrators to restrict which features and data sections each dashboard user can access. RBAC is built around roles and permissions: a role bundles a set of permissions and is assigned to one or more users.

When RBAC is enabled, a user must hold a role that explicitly grants the required access. Without a matching permission, the request is denied regardless of the user's account type.


Enabling RBAC

RBAC can be enabled at two levels:

Tenant-wide — activates enforcement across all brands in the tenant:

Settings → Security → RBAC Enforcement

Per brand — activates enforcement for one specific brand only, regardless of the tenant-wide setting:

Switch into the target brand → Settings → Security → RBAC Enforcement

A brand with RBAC enabled enforces permissions for its users even if the tenant-wide switch is off.

Developer session toggle — for testing without changing persistent settings, any Unidy user can toggle RBAC for their own browser session via the user menu: click your name in the top-right corner and select Enable RBAC / Disable RBAC. This sets a short-lived cookie and has no effect on other users or on the tenant/brand configuration.


Scopes

Unidy permissions operate in two scopes:

Scope
Description
Global
Applies tenant-wide, independent of any specific brand
Brand
Applies to resources within one specific brand

A user holding a global roles: write permission can manage roles across all brands. A user with only a brand-scoped roles: read permission can view roles for that brand only.


Permission Resources

Permissions are organised in a three-level hierarchy:

data/                          ← top-level category
  users/                       ← sub-group
    users                      ← individual resource
  newsletters/
    newsletter_preference_groups
    newsletter_preferences
    newsletter_subscriptions
  subscriptions/
    subscriptions
  tickets/
    tickets
  ...
customization/
  ...
settings/
  team_and_permissions/
    roles
  ...

Each level can be assigned an action independently. Setting a category or sub-group to an action applies it uniformly to all resources beneath it. Setting it to Custom allows each child to be configured individually.

Action
Description
none
No access
read
View records only
write
Create and update records
delete
Delete records
manage
Full access — implies read, write, and delete
custom
Sub-resources are configured individually

Actions are cumulative: manage implies all lower actions. Granting write on data/users/ automatically grants read on the parent data/ category.


Predefined Roles

Unidy ships with system-managed predefined roles that cannot be modified or deleted:

Role
Scope
Permissions
Tenant Admin
Global
Full access across all brands and tenant settings
Brand Admin
Brand
Full access to data and customization within one brand
Newsletter Subscriptions Admin
Brand
Manage newsletter subscriptions and associated user data
User Admin
Brand
Manage user profiles within a brand
Viewer
Brand
Read-only access to data within a brand

Predefined roles are created automatically when a new brand is added. If they are missing, they can be regenerated from Auth → Roles → Recreate predefined roles without affecting existing roles.


Custom Roles

Tenant administrators can create custom roles:

  • Auth → Roles — tenant-wide (global) roles applying across all brands
  • Customization → Roles — brand-scoped roles applying within a single brand

Global roles have no brand_id. Brand-scoped roles are tied to a specific brand.


API Enforcement

When RBAC is enabled, all Unidy API calls and dashboard actions are subject to permission checks. A request from a user without the required permission returns:

HTTP 403 Forbidden

RBAC enforcement applies consistently to the dashboard UI and all SDK/API endpoints.


Brand Isolation

Each brand has its own independent set of roles. A user assigned Brand Admin for Brand A has no access to Brand B. To grant cross-brand access, assign roles per brand individually or use a global role.

Did this answer your question?
😞
😐
🤩