# How to implement multitier user access roles in Bubble.io: Step-by-Step Guide

- Tool: Bubble
- Difficulty: Beginner
- Time required: 25-30 min
- Compatibility: All Bubble plans
- Last updated: March 2026

## TL;DR

Implement a multi-tier role system in Bubble with hierarchical permissions where Admins can do everything Managers can, and Managers can do everything Users can. This tutorial covers creating a role hierarchy with an Option Set, enforcing access through Privacy Rules and conditional visibility, and dynamically generating menus based on each user's role level.

## Overview: Multi-Tier User Access Roles in Bubble

Most apps need more than a simple admin/user split. This tutorial builds a hierarchical permission system where each role tier inherits all permissions from the tier below. You will use an Option Set with a numeric rank to create the hierarchy, enforce access server-side with Privacy Rules, control UI visibility with conditions, and generate navigation menus dynamically so each role sees only the features they can access.

## Before you start

- A Bubble account with an app that has user registration and login
- Basic understanding of Privacy Rules in the Data tab
- Familiarity with conditional visibility on elements
- At least two test user accounts for verifying role restrictions

## Step-by-step guide

### 1. Create the Role Option Set with a rank attribute

Go to Data tab → Option sets and create a new Option Set called Role. Add an attribute called Rank of type number. Now add the options: User (Rank = 1), Manager (Rank = 2), Admin (Rank = 3), Super_Admin (Rank = 4). The rank number represents the permission level — higher ranks inherit all lower-rank permissions. Next, go to Data tab → Data types, select the User type, and add a field called Role of type Role (the Option Set you just created). Set the default value to User so every new signup gets the base role.

> Pro tip: Using a numeric rank attribute instead of checking role names directly makes it easy to add new tiers later without changing conditions everywhere.

**Expected result:** A Role Option Set with ranked tiers and a Role field on the User Data Type.

### 2. Set up Privacy Rules based on role rank

Go to Data tab → Privacy. For each Data Type that needs role-based access, create Privacy Rules using the rank attribute. For example, on a Data Type called Report: create a rule named 'Manager+ can view' with condition 'Current User's Role's Rank >= 2' and check 'Find this in searches' and 'View all fields.' For a Data Type called Settings: create a rule 'Admin+ can view' with condition 'Current User's Role's Rank >= 3'. This pattern uses >= comparisons so that higher roles automatically inherit lower-role permissions without listing each role individually.

**Expected result:** Privacy Rules restrict data access based on the user's role rank, with higher ranks automatically gaining access to everything lower ranks can see.

### 3. Add page-level access redirects

On each restricted page, add a workflow event: 'Page is loaded' with a condition 'Only when Current User's Role's Rank < [minimum required rank].' In this workflow, add the action 'Go to page' and redirect to an 'unauthorized' page or the home page. For example, on the admin-dashboard page, set the condition to 'Only when Current User's Role's Rank < 3' → Go to page home. This ensures users who navigate directly to a restricted URL are redirected immediately. Create the redirects for each restricted page with the appropriate minimum rank.

> Pro tip: Also hide navigation links to restricted pages using conditions — this prevents users from seeing links they cannot access, while the page-level redirect serves as a safety net.

**Expected result:** Users who try to access pages above their role tier are automatically redirected away.

### 4. Build conditionally visible UI elements per role

For elements that should only appear for certain roles, select the element and go to the Conditional tab. Add a condition: 'When Current User's Role's Rank < [minimum rank] → This element is visible: no.' For example, a 'Manage Users' button should have condition 'When Current User's Role's Rank < 3 → visible: no.' An 'Edit' button available to managers and above: 'When Current User's Role's Rank < 2 → visible: no.' Always check 'Collapse when hidden' in the Layout tab so hidden elements do not leave gaps. Remember that hiding an element does not secure the underlying data — Privacy Rules handle actual security.

**Expected result:** UI elements appear or disappear based on the logged-in user's role rank.

### 5. Create a dynamic navigation menu based on role

Create a Data Type called NavItem with fields: Label (text), Page_URL (text), Icon (text or image), Min_Rank (number), and Sort_Order (number). Add records for each navigation item: Dashboard (Min_Rank=1, Sort=1), Reports (Min_Rank=2, Sort=2), User Management (Min_Rank=3, Sort=3), System Settings (Min_Rank=4, Sort=4). On your navigation bar, add a Repeating Group with Type: NavItem, Data source: Do a search for NavItems where Min_Rank <= Current User's Role's Rank, sorted by Sort_Order ascending. In each cell, display the Label as a clickable link that navigates to the Page_URL.

> Pro tip: Using a database-driven navigation menu means you can add or rearrange menu items without touching the page design — just add a new NavItem record.

**Expected result:** The navigation menu dynamically shows only the items the current user's role has permission to access.

### 6. Build an admin panel for managing user roles

Create a page called manage-users accessible only to Admin+ (add the page-level redirect for Rank < 3). Add a Repeating Group with Type: User, Data source: Do a search for Users. In each cell, show the user's email, current Role Display, and a Dropdown with data source: All Roles. Set the Dropdown's default value to Current cell's User's Role. Create a workflow: When Dropdown value changes → Make changes to Current cell's User → Role = This Dropdown's value. Add a condition on the Dropdown: disable it when Current cell's User's Role's Rank >= Current User's Role's Rank — this prevents users from editing roles of equal or higher rank than themselves.

> Pro tip: For teams with many users, RapidDev can help architect advanced permission systems with feature-level access flags, role groups, and audit logging for compliance requirements.

**Expected result:** Admins can view all users and change their roles via a dropdown, with protection against privilege escalation.

## Complete code example

File: `Workflow summary`

```text
MULTI-TIER ROLE SYSTEM — WORKFLOW SUMMARY
==========================================

OPTION SET: Role
  User        → Rank: 1
  Manager     → Rank: 2
  Admin       → Rank: 3
  Super_Admin → Rank: 4

DATA TYPE: User (modified)
  + Role (Role Option Set, default: User)

DATA TYPE: NavItem
  Label (text), Page_URL (text), Icon (text),
  Min_Rank (number), Sort_Order (number)

PRIVACY RULES PATTERN:
  Rule: [Role]+ can access
  Condition: Current User's Role's Rank >= [minimum rank]
  Permissions: Find in searches, View all fields

PAGE-LEVEL REDIRECTS:
  Event: Page is loaded
  Only when: Current User's Role's Rank < [page minimum rank]
  Action: Go to page → home (or unauthorized page)

CONDITIONAL VISIBILITY:
  Element Conditional tab:
  When Current User's Role's Rank < [min rank]
  → This element is visible: no
  Layout: Check 'Collapse when hidden'

DYNAMIC NAVIGATION:
  Repeating Group → Type: NavItem
  Source: Search NavItems (Min_Rank <= Current User's Role's Rank)
  Sorted by: Sort_Order ascending
  Each cell: Label as link → navigates to Page_URL

ROLE MANAGEMENT PAGE: manage-users (Admin+ only)
  Repeating Group → Type: User, Source: Search all Users
  Each cell: Email, Current Role, Role Dropdown
  Workflow: Dropdown changes → Make changes to User → new Role
  Guard: Disable dropdown when cell User's Rank >= Current User's Rank
```

## Common mistakes

- **Using role names in conditions instead of numeric rank comparisons** — Checking names like 'Current User's Role is Admin OR Current User's Role is Super_Admin' requires updating every condition when you add a new role tier. Fix: Use rank comparisons: 'Current User's Role's Rank >= 3' automatically includes all roles at rank 3 and above.
- **Relying on UI hiding for security instead of Privacy Rules** — Hidden elements can be revealed through browser developer tools. Without Privacy Rules, the underlying data is still accessible. Fix: Always enforce access through Privacy Rules on the Data tab. Use conditional visibility only for UX, not security.
- **Allowing users to assign roles equal to or above their own rank** — This enables privilege escalation — a Manager could make themselves an Admin. Fix: Add a condition on the role assignment: only allow changing to roles with a Rank lower than the current user's Rank.

## Best practices

- Use numeric rank attributes on Option Sets for flexible, scalable role hierarchies
- Enforce access server-side with Privacy Rules — never rely solely on UI visibility for security
- Add page-level redirects as a safety net even when navigation links are hidden
- Store navigation items as database records for easy menu management without design changes
- Check 'Collapse when hidden' on all conditionally visible elements to prevent layout gaps
- Test every page as each role tier using the 'Run as' feature in preview mode
- Log role changes to an AuditLog Data Type for accountability and troubleshooting

## Frequently asked questions

### Can I have more than four role tiers?

Yes. Add as many options to the Role Option Set as you need, each with a unique Rank number. The rank-based comparison pattern works with any number of tiers.

### How do I assign roles during user registration?

In the Sign up workflow, the User's Role field automatically gets the default value you set (User). For special roles, create an admin-only workflow that changes the user's Role after registration.

### What if a user needs different roles for different features?

For feature-level permissions beyond a simple hierarchy, add individual yes/no fields to the User type (e.g., can_export, can_invite) or create a Permissions Data Type with granular flags linked to each role.

### Do Privacy Rules based on role rank affect app performance?

Privacy Rules add minimal overhead. Bubble evaluates them server-side during data queries. The rank comparison is a simple numeric check and does not noticeably impact performance.

### How do I prevent a Super Admin from accidentally demoting themselves?

Add a condition on the role Dropdown: disable it when Current cell's User is Current User. This prevents any user from changing their own role.

### Can RapidDev help set up enterprise-grade role systems?

Yes. RapidDev specializes in building complex permission architectures including feature-level access matrices, team-scoped roles, and audit logging for compliance-sensitive applications.

---

Source: https://www.rapidevelopers.com/bubble-tutorial/implement-multitier-user-access-roles-in-bubble
© RapidDev — https://www.rapidevelopers.com/bubble-tutorial/implement-multitier-user-access-roles-in-bubble