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.
Prerequisites
- 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
Create the Role Option Set with a rank attribute
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.
Set up Privacy Rules based on role rank
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.
Add page-level access redirects
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.
Build conditionally visible UI elements per role
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.
Create a dynamic navigation menu based on role
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.
Build an admin panel for managing user roles
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 working example
1MULTI-TIER ROLE SYSTEM — WORKFLOW SUMMARY2==========================================34OPTION SET: Role5 User → Rank: 16 Manager → Rank: 27 Admin → Rank: 38 Super_Admin → Rank: 4910DATA TYPE: User (modified)11 + Role (Role Option Set, default: User)1213DATA TYPE: NavItem14 Label (text), Page_URL (text), Icon (text),15 Min_Rank (number), Sort_Order (number)1617PRIVACY RULES PATTERN:18 Rule: [Role]+ can access19 Condition: Current User's Role's Rank >= [minimum rank]20 Permissions: Find in searches, View all fields2122PAGE-LEVEL REDIRECTS:23 Event: Page is loaded24 Only when: Current User's Role's Rank < [page minimum rank]25 Action: Go to page → home (or unauthorized page)2627CONDITIONAL VISIBILITY:28 Element Conditional tab:29 When Current User's Role's Rank < [min rank]30 → This element is visible: no31 Layout: Check 'Collapse when hidden'3233DYNAMIC NAVIGATION:34 Repeating Group → Type: NavItem35 Source: Search NavItems (Min_Rank <= Current User's Role's Rank)36 Sorted by: Sort_Order ascending37 Each cell: Label as link → navigates to Page_URL3839ROLE MANAGEMENT PAGE: manage-users (Admin+ only)40 Repeating Group → Type: User, Source: Search all Users41 Each cell: Email, Current Role, Role Dropdown42 Workflow: Dropdown changes → Make changes to User → new Role43 Guard: Disable dropdown when cell User's Rank >= Current User's RankCommon mistakes when implementing multitier user access roles in Bubble.io: Step-by-Step Guide
Why it's a problem: Using role names in conditions instead of numeric rank comparisons
How to avoid: Use rank comparisons: 'Current User's Role's Rank >= 3' automatically includes all roles at rank 3 and above.
Why it's a problem: Relying on UI hiding for security instead of Privacy Rules
How to avoid: Always enforce access through Privacy Rules on the Data tab. Use conditional visibility only for UX, not security.
Why it's a problem: Allowing users to assign roles equal to or above their own rank
How to avoid: 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
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I'm building a Bubble.io app that needs multi-tier user roles: User, Manager, Admin, and Super Admin. Each higher role should inherit all permissions from lower roles. Can you help me design the role hierarchy and explain how to enforce it with Privacy Rules?
Set up a role-based access system in my app. I need an Option Set called Role with ranked tiers (User, Manager, Admin, Super_Admin) and Privacy Rules that use the rank number to control access to different Data Types.
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.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation