🚧

User-level permissions are only available on Business and Enterprise plans. All accounts on Free and Team plans have global Edit access by default and group attributes cannot be modified.

As a Retool admin, you can use Permission Groups to control which users have access to specific apps and resources. See Inviting users and authentication to learn how to invite users to Retool.

If you can't see Organization Settings > Permissions your account is not an admin and will not be able to perform the tasks described in this guide.

Managing users individually

The Users page displays all invited, suggested, enabled, and disabled users in your org.

You can search users by name or email, sort by name or when they were last active, and filter the list by user type.

Filtering users

While on the Users page, you can select the filter dropdown to select which users should be displayed. Please note that disabled users do not appear with the All users filter by default, and can only be viewed when the Disabled users filter is explicitly selected.

Updating a specific user

On the Users page, you can also select any individual user. Once a user is selected, you'll see a modal that gives you more access and status details about the user.

When a user account is pending in the invited or suggested status, you'll have additional options to manage the pending state.

For invited users, the invite can be revoked, or resent. Invited users can also be added to permission groups which will determine their access when they first login.

For suggested users, the request can be declined or approved by admins. These users cannot be added to groups until approved.

🚧

Group membership

You cannot add suggested users to permission groups. Only approved invites and accepted users can be added to groups.

While in this user modal, you can also navigate to the Apps tab to show a list of folders and pages that the user is able to access, with the corresponding access level shown for each item. Items listed here represent access across all of a users groups.

Managing users at the group level

Within Retool, admins manage permissions by creating access groups. Every org has at least 4 default groups. These groups have the following special properties which cannot be changed:

• All Users: every user within your organization will belong to this group, and the membership cannot be altered.
• Viewer: a group with configurable membership where every member has "Use" access to all of Retool.
• Editor: a group with configurable membership where every member has "Edit" access to all of Retool.
• Admin: members of this group have "Own" access to all apps, folders, and resources, and can modify organization level settings.

From the groups page, you can see how many apps, resources, and members belong to each group. You can also quickly add members to a group by clicking on the users:

Group Admins

Admins can assign Group Admins to manage membership for any custom groups. They can grant any number of group members the Group Admin privileges to add new users or remove existing users. Group Admins will be able to see all users within an org, but are not able to modify any aspect of their group beyond membership (e.g. app and resource permissions).

Configuring group permissions

To configure a group, click its name or Edit to access the group detail page. Here, you can configure group membership, the apps, folders, and resources a group can access, and other additional settings.

👍

Saving Changes

Within the group detail page, any changes you make will be in a draft state until Save changes is clicked. When you're finished editing, remember to click Save changes for your updates to take effect!

Managing group access to apps

For a Retool app, there are 3 tiers of access:

• Use: open apps in end-user mode only with no editor access.
• Edit: make changes to components, temporary states, transformers, and all queries that are for resources that the user has access to.
• Own: all edit access, and the ability to delete apps permanently.

These can be set globally, for an entire folder with a folder default, or for specific pages. The checkbox selections cascade for folders, so it's easy to quickly add many apps to a group.

Managing group access to folders

Setting a permission for an app folder will affect all new apps that are created or moved to that folder. For Own and Edit folder permissions, users will also have the ability to create new apps within that folder.

📘

Folder Permissions

Clicking a folder's access level checkbox will update the permission of every app within it, and set the folder's permission to that access level. However, updating the folder's permission will not update the child apps, it will only affect new apps.

Managing resource permissions

Resource permissions have two tiers of access: Use and Edit. Use allows users to view the resource's configuration, and write queries against it in creator mode. Edit includes Use permissions and also allows users to update the resource's configuration.

Like app permissions, resource permissions can be set globally, for an entire resource folder with a folder default, or for specific resources. The checkbox selections cascade for folders so you can add multiple resources to a group.

📘

Resource Permissions

Users with Use access to an app can trigger all queries within that app, even if they don't explicitly have access to a resource used. However, they can't edit and save queries that use resources they don't have permission to use.

Managing group access to resource folders

Setting permissions for a resource folder affects all new resources created or moved to that folder. Users in groups with Edit resource folder permissions also have the ability to create new resources within that folder.

Note that only admins and users in groups with Edit all resource access can create new resource folders.

Managing additional access

Groups can also have a configurable Workspace, Query library access, and access to the user list.

Managing component permissions

In the left panel of the editor, there is a current_user object that has metadata about the current user that is logged in, including their permission groups. You can disable buttons or hide components by using the current_user object in JS expressions within {{ }}.

For example, in a Hide when true field for a button, you could write {{current_user.groups.map(group => group.name).includes('Marketing')}} to hide that button for users in the Marketing permission group.

Managing record-level permissions

You can restrict access to database records by referencing attributes on the current_user object in your query logic. For example, current_user.email uniquely identifies the user running the query. Retool instances integrated with OpenID SSO providers also expose identifying information on the current_user.metadata.idToken object.

As an example, let’s say you’re building a Retool app that displays data about an employee’s compensation. This information is confidential, and should only be viewable by an employee’s manager. Your employees table contains a manager field, populated with the manager’s email address. You can use the following query to restrict access to the appropriate manager:

SELECT
  *
FROM
  employees
WHERE
  manager = {{current_user.email}};

Preventing query spoofing

Retool uses prepared statements to transmit query variables to your database as part of the network request. To prevent a user from manipulating the network request to pass in arbitrary values to the prepared statement, you can enable the Prevent query variable spoofing feature under Settings > Beta.

When this feature is enabled, Retool rejects network requests that refer to current_user attributes that don’t match the expected values for the user making the query.

🚧

This feature is only compatible with simple JavaScript expressions that reference a specific attribute of the current_user object. If you include additional logic in your expression, query spoofing prevention will be disabled:

✅ {{current_user.email}}
❌ {{current_user.groups.map(group => group.name)}}