Skip to main content
RapidDev - Software Development Agency
retool-tutorial

How to Set Up Role-Based Access Control in Retool

Retool's RBAC system is configured in Settings → Roles & Permissions. The four default groups (Admin, All Users, Editor, Viewer) cover most use cases. Business+ plans allow custom groups with granular scopes. Use {{ current_user.groups.includes('groupName') }} in component Hidden or Disabled properties to show/hide features based on the current user's role.

What you'll learn

  • How Retool's permission groups (Admin, All Users, Editor, Viewer) work
  • How to create custom permission groups on Business+ plans
  • The difference between system-wide RBAC and per-app user permissions
  • How to restrict UI elements using {{ current_user.groups }} in expressions
  • How to configure granular permission scopes for resource access and app operations
Book a free consultation
4.9Clutch rating
600+Happy partners
17+Countries served
190+Team members
Intermediate8 min read20-30 minRetool Cloud and Self-hostedLast updated March 2026RapidDev Engineering Team
TL;DR

Retool's RBAC system is configured in Settings → Roles & Permissions. The four default groups (Admin, All Users, Editor, Viewer) cover most use cases. Business+ plans allow custom groups with granular scopes. Use {{ current_user.groups.includes('groupName') }} in component Hidden or Disabled properties to show/hide features based on the current user's role.

Quick facts about this guide
FactValue
ToolRetool
DifficultyIntermediate
Time required20-30 min
CompatibilityRetool Cloud and Self-hosted
Last updatedMarch 2026

Org-Wide Roles and Permission Groups in Retool

Role-based access control (RBAC) in Retool operates at two levels: the organization level (who can build apps, manage resources, and access settings) and the application level (who can view or edit specific apps). This tutorial focuses on the organization-level RBAC, which is the foundation for controlling what different user types can do in your Retool instance.

Retool provides four built-in permission groups: Admin (full access), Editor (can build apps, cannot manage settings), Viewer (can use apps, cannot edit them), and All Users (a group every member belongs to). Business and Enterprise plans allow creating custom groups with specific permission scopes tailored to your organizational roles.

In addition to system-level groups, you can reference current_user.groups in any {{ }} expression to conditionally show or hide UI elements, gate actions, or filter data based on the logged-in user's group membership.

Prerequisites

  • Admin access to a Retool organization
  • Retool Cloud or Self-hosted instance
  • Basic understanding of Retool's user management
  • Business+ plan required for custom permission groups (built-in groups work on all plans)

Step-by-step guide

1

Navigate to Settings → Roles & Permissions

Log in as an Admin. Click the gear icon in the top-right corner of the Retool editor or navigate to your-retool-instance.com/settings. In the Settings sidebar, find and click 'Roles & Permissions' (may appear as 'Permission Groups' depending on your Retool version). This page lists all existing permission groups and their assigned users.

Expected result: The Roles & Permissions page shows the four built-in groups: Admin, All Users, Editor, and Viewer, with their member counts.

2

Understand the four built-in permission groups

Retool ships with four default groups that cannot be deleted. Admin: full access to everything — app creation, resource management, user management, settings, billing. Editor: can create and edit apps, create and use resources, but cannot manage users or billing. Viewer: can use (run) apps but cannot edit or create them. All Users: automatically includes every member of the organization — permissions set here apply universally.

typescript
1// Built-in groups and their key capabilities:
2// Admin:
3// - Create/edit/delete apps
4// - Manage resources (databases, APIs)
5// - Manage users and groups
6// - Access org settings and billing
7// - Access audit logs
8
9// Editor:
10// - Create/edit apps
11// - Create/manage resources
12// - Cannot manage users, billing, or org settings
13
14// Viewer:
15// - Use (run) apps
16// - Cannot create or edit apps
17// - Cannot access resources or settings
18
19// All Users:
20// - Every member is automatically in this group
21// - Useful for org-wide defaults (e.g., read access to certain apps)

Expected result: You understand what each built-in group can and cannot do before customizing.

3

Create a custom permission group (Business+ plans)

On Business and Enterprise plans, click '+ New group' in the Roles & Permissions page. Name the group after your organizational role (e.g., 'Sales', 'Support', 'Finance'). After creating the group, click on it to edit its permission scopes. You will see a list of scope checkboxes organized by category: Apps, Resources, Workflows, Settings, Users. Enable only the scopes needed for that role. Free and Pro plans are limited to the four built-in groups.

typescript
1// Example: Support Agent group configuration
2// ✓ Use apps (can run apps they have access to)
3// ✓ View app list (can see available apps)
4// ✗ Create apps (cannot build new tools)
5// ✗ Manage resources (cannot modify database connections)
6// ✗ Invite users (cannot add team members)
7// ✗ View audit log (no access to security logs)
8
9// Retool Free/Pro: 11 permission scopes available
10// Retool Business: 30 permission scopes available

Expected result: The custom group appears in the Roles & Permissions list. You can assign users to it and it appears in current_user.groups for members.

4

Assign users to permission groups

Click on a permission group to open its detail view. In the Members tab, click '+ Add member'. Select users from your org's user list to add them to the group. Users can belong to multiple groups — their effective permissions are the union of all groups they belong to. To remove a user, click the trash icon next to their name in the Members tab.

Expected result: Selected users appear in the group's Members list. Their Retool access now reflects the group's permission scopes.

5

Use {{ current_user.groups }} to gate UI elements

In any Retool app, the current_user object exposes the logged-in user's groups as an array of strings. Use this in {{ }} expressions to conditionally show, hide, or disable UI elements based on role. This gives you granular in-app access control that complements the system-level RBAC. Note: this is UI-level control — always enforce permissions at the query/API level as well.

typescript
1// Show a Delete button only for Admin users:
2// Button Hidden property:
3{{ !current_user.groups.includes('admin') }}
4
5// Show a Salary column only for HR or Admin:
6// Table column Hidden property:
7{{ !current_user.groups.some(g => ['hr', 'admin'].includes(g)) }}
8
9// Show different views based on role:
10// Manager view Container Hidden:
11{{ !current_user.groups.includes('managers') }}
12// Employee view Container Hidden:
13{{ current_user.groups.includes('managers') }}
14
15// Display current user info in a Text component:
16{{ `Logged in as: ${current_user.fullName} (${current_user.groups.join(', ')})` }}

Expected result: UI elements show or hide based on the logged-in user's group membership, creating a role-specific interface.

6

Configure per-app access separately from org-wide groups

Beyond org-wide groups, each individual app has its own access control. In the app editor, click Share (top-right) to see the app's access list. You can grant individual users or groups Use (can run), Edit (can modify), or Own (can delete and share) access to the specific app. This is additive — a user needs both org-level permissions AND app-level access to use an app. The RBAC tutorial covers org-level; for app-level see the user permissions tutorial.

Expected result: The app's sharing settings show the access levels for each user and group. Changes take effect immediately.

Complete working example

JS Query: enforceRoleBasedQueryExecution
1// Enforce role-based query execution server-side
2// (UI-level checks are UX only — always enforce at query level too)
3
4const userGroups = current_user.groups;
5const userEmail = current_user.email;
6
7// Define which groups can perform each action
8const CAN_DELETE = ['admin', 'managers'];
9const CAN_EXPORT = ['admin', 'finance', 'managers'];
10const CAN_VIEW_PII = ['admin', 'hr', 'managers'];
11
12// Check if user has required permission
13function hasPermission(action) {
14 const allowedGroups = {
15 delete: CAN_DELETE,
16 export: CAN_EXPORT,
17 viewPII: CAN_VIEW_PII
18 };
19 return userGroups.some(g => allowedGroups[action]?.includes(g));
20}
21
22// Example: Guard a delete operation
23if (!hasPermission('delete')) {
24 console.warn(`User ${userEmail} attempted delete without permission`);
25 utils.showNotification({
26 title: 'Permission denied',
27 description: 'Only Admins and Managers can delete records.',
28 notificationType: 'error'
29 });
30 return;
31}
32
33// Proceed with the operation
34await deleteRecord.trigger({
35 additionalScope: { id: table1.selectedRow.data.id }
36});
37
38utils.showNotification({ title: 'Record deleted', notificationType: 'success' });
39await getRecords.trigger();

Common mistakes

Why it's a problem: Using current_user.groups for security-critical restrictions without backing them up with server-side query guards

How to avoid: UI checks (Hidden property, 'Only run when') can be bypassed by tech-savvy users. Add role checks in JS Queries that execute the sensitive actions as an additional enforcement layer.

Why it's a problem: Group names are case-sensitive — 'Admin' and 'admin' are different groups

How to avoid: Standardize on lowercase group names in your organization. Use current_user.groups.map(g => g.toLowerCase()).includes('admin') for case-insensitive checks.

Why it's a problem: Expecting RBAC changes to take effect without the user refreshing or re-logging in

How to avoid: Retool re-evaluates group membership on each page load. Permission changes take effect the next time the user refreshes or opens the app. For SSO users, a new SSO sign-in may be required.

Why it's a problem: Confusing org-level RBAC groups with app-level sharing permissions

How to avoid: Org RBAC (Settings → Roles & Permissions) controls what actions a user can perform across the org. App sharing (Share button) controls access to specific apps. A user needs both: the org-level permission to use apps AND specific access to the app.

Best practices

  • Always enforce permissions at the query level (in JS Queries), not just via Hidden/Disabled UI properties — UI-side checks are UX, not security.
  • Keep group names lowercase and consistent (e.g., 'admin', 'managers', 'support') to avoid case-sensitivity bugs in current_user.groups.includes() checks.
  • Use the 'All Users' group for baseline permissions that every org member should have, then grant additional scopes via specific groups.
  • Audit permission group membership regularly — employees change roles, and stale group assignments create security gaps.
  • On Business+ plans, create role-based groups that match your org chart (Finance, HR, Ops, Support) rather than creating permission groups per app.
  • Document your RBAC design in a Retool app or wiki so new admins understand the intended role structure.
  • When using SSO (SAML/OIDC), configure group mapping in your IdP to automatically assign Retool groups based on directory groups.

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

ChatGPT Prompt

I am setting up RBAC in Retool for my organization. I have four teams: Sales (can use apps), Support (can use apps), Finance (can use apps and export data), and Managers (can use and edit apps, see salary data). How do I: (1) create custom permission groups for each team, (2) assign the right permission scopes to each, (3) use {{ current_user.groups }} to show a salary column only for HR and Managers, and (4) enforce these checks in JS Queries to prevent API-level bypass?

Retool Prompt

In my Retool app, write a {{ }} expression for a Table column's Hidden property that hides the 'Salary' column unless the current user belongs to the 'hr' or 'admin' group. Also write a JS Query guard that checks current_user.groups before running a deleteRecord query, and shows a utils.showNotification() error if the user is not in the 'admin' or 'managers' group.

Frequently asked questions

What is the difference between Retool's RBAC and per-app permissions?

RBAC (Settings → Roles & Permissions) controls what a user can do across the entire organization — building apps, managing resources, accessing settings. Per-app permissions (Share button on each app) control which users or groups can view or edit that specific app. A user needs both: org-level permission to use apps AND app-level access to run the specific app.

Can I restrict which databases a specific user group can query in Retool?

Yes, on Business and Enterprise plans. In Settings → Roles & Permissions, custom groups have granular resource access scopes. You can grant a group access to specific resources (e.g., read-only PostgreSQL) while denying access to others (e.g., write access or different databases). Free and Pro plans use the built-in Editor/Viewer distinction, where Editors have access to all resources.

Does current_user.groups work in Retool public apps?

In public apps (unauthenticated), current_user is not available and current_user.groups will be an empty array or undefined. Always check that current_user exists before accessing its properties in apps that support both authenticated and unauthenticated access.

RapidDev

Talk to an Expert

Our team has built 600+ apps. Get personalized help with your project.

Book a free consultation

Learning is great. Shipping is faster with help.

Our engineers have built 600+ apps on Retool and the tools around it. If your project needs to be live sooner than your learning curve allows — book a free consultation.

Book a free consultation

We put the rapid in RapidDev

Need a dedicated strategic tech and growth partner? Discover what RapidDev can do for your business! Book a call with our team to schedule a free, no-obligation consultation. We'll discuss your project and provide a custom quote at no cost.