How to Set Up User Permissions in Retool

Open the app in edit mode. Click the Share button in the top-right toolbar (it looks like a person with a + symbol). The Share panel opens showing the current access list for this app: which users and groups have Use, Edit, or Own access. By default, newly created apps may only be visible to Admins and the creator.

Each app has three access levels. Use: the user can open and run the app, trigger queries, interact with all components — but cannot modify the app's design or logic. Edit: the user can modify the app, add components, change queries, and update settings. Own: the user can delete the app, manage its sharing settings, and do everything Edit can do. Most end users should have Use access only.

1// App access levels comparison:
2// Use:
3//   - Open and run the app
4//   - Trigger queries (click buttons, submit forms)
5//   - See all components visible to their role
6//   - Cannot: edit app design, add queries, change settings
7
8// Edit:
9//   - All of Use
10//   - Modify app components, queries, event handlers
11//   - Change app settings
12//   - Cannot: delete app, manage sharing
13
14// Own:
15//   - All of Edit
16//   - Delete the app
17//   - Manage app sharing settings
18//   - Usually: the app creator + senior builders

In the Share panel, click '+ Add' (or 'Invite people') to add a user or group. Type the user's email or group name. Select the access level (Use, Edit, or Own) from the dropdown. Click Save or Confirm. Repeat for each user or group. You can also select a group like 'Finance' or 'Support' to grant access to all members at once instead of individual users.

The All Users group contains every member of your Retool organization. If you grant Use access to All Users on an app, every org member can run it. This is appropriate for truly org-wide tools (company directory, IT request form). For department-specific apps, do not grant All Users access — restrict to specific groups. You can configure All Users access in the Share panel the same way as any other group.

Within an app, reference the current logged-in user's groups to show or hide components. The current_user object has groups (array of group names), email, fullName, and id properties. Use these in Hidden, Disabled, and other Inspector property fields to create differentiated interfaces for different roles without building separate apps.

1// Show a Manager-only section:
2// Container Hidden property:
3{{ !current_user.groups.includes('managers') }}
4
5// Show Delete button only for Admin:
6// Button Hidden property:
7{{ !current_user.groups.includes('admin') }}
8
9// Show different tabs based on role:
10// Tab 'Overview' — visible to all (no Hidden condition)
11// Tab 'Analytics' — Hidden: {{ !current_user.groups.some(g => ['managers', 'admin'].includes(g)) }}
12// Tab 'Settings' — Hidden: {{ !current_user.groups.includes('admin') }}
13
14// Show user's own records only for non-managers:
15// This goes in a SQL query's WHERE clause:
16// WHERE (assigned_to = {{ current_user.email }}
17//   OR {{ current_user.groups.includes('managers') }})

Beyond hiding UI elements, you can use current_user properties to filter the data returned by queries. For example, a sales rep should only see their own leads, while a manager sees all leads. Reference current_user.email or current_user.id in SQL WHERE clauses to apply row-level data restrictions per user.

1-- SQL Query: getMyLeads
2-- Shows the current user's leads, or all leads for managers
3SELECT l.*, u.name as owner_name
4FROM leads l
5JOIN users u ON u.id = l.assigned_to
6WHERE 
7  -- Non-managers see only their leads
8  (
9    {{ current_user.groups.includes('managers') }}
10    OR l.owner_email = {{ current_user.email }}
11  )
12ORDER BY l.created_at DESC;