Governance in Retool
Learn about governance in Retool.
Retool offers a powerful set of governance features that enable organizations to control, secure, and efficiently manage apps, workflows, and access to data. This guide explains ways to build a strong governance model in Retool, organized around the three levels of access management in Retool:
- Organizational access: who is allowed to use Retool, and who is not?
- Project access: within an organization, which Retool apps or workflows is a user allowed to use?
- Data access: within a project, what data is a user allowed to view and update?
Organizational access
Organizational access refers to how users in your company gain access to Retool. While an access approval process might happen outside of Retool (e.g., users request access in your company's ticketing system), Retool provides several ways to facilitate this access.
Integrate with your identity provider
You can set up login, map groups, and provision users by integrating Retool with a supported identity provider (IdP). Retool supports Google LDAP, and identity providers that support OpenID and SAML authorization protocols.
User provisioning
Users can be provisioned into Retool directly through SSO, invitation, and access requests. Refer to the user management tutorial.
If you want users to automatically be provisioned Retool accounts when visiting Retool's login page, you can set up just-in-time provisioning. If the user exists in your identity provider but not yet in Retool, Retool automatically creates a user account and grants them organizational access. To make sure their access is scoped to the right project, you can map groups and roles directly to the custom groups you set up in Retool. See Role-based access controls for more.
Spaces
Large organizations have many different teams and use cases that often operate independently. You can set up Spaces to enable isolation of teams and development workflows, without needing to create a separate Retool account if you're on cloud or spin up separate Retool instances if you're self-hosting.
In some cases, it may make sense to deploy several instances in separate VPCs to ensure network isolation between development and production instances. See scale your Retool organization for more.
Programmatic management
Organizations on the Enterprise plan can programmatically create Spaces, set organizational settings, and configure SSO through the Retool API. This allows you hook into your existing systems and centralize governance across your different teams using Retool.
Project access
Project access refers to managing users' access to the different use cases–groups of apps, workflows, queries–you're using Retool for. For example, a project could be a suite of Retool apps built to allow your Support team to more easily work with data and update customer information. These are often organized in several folders in a given Retool organization or Space.
Role-based access controls
Retool's role-based access controls let you manage access to Retool apps, folders, Workflows, resources, queries, and more. You can create multiple custom permission groups, assign access levels to Retool apps, and delegate Group Admin responsibility to users for them to manage group membership.
Users who do not have access to Retool apps cannot see them in the application listing.
Learn more about role-based access controls.
Direct access sharing
Sometimes, it may be too much overhead for an admin to create a permission group to facilitate one-off access to Retool apps. When enabled, direct access sharing lets users with Own access to an app manage its permissions. You can audit access to an app and learn how access is granted—directly or from permission groups—from an app's access list in the application listing.
Data access
Data access concerns a user's ability to see or edit sensitive data within Retool apps. In Retool, restricting access to apps displaying or working with sensitive data implicitly means restricting access to the data itself. Retool has controls to make sure editors and viewers can only see data they're allowed to see.
Resource environments
Resource environments allow admins to configure resources that point to sensitive and nonsensitive data. Retool also supports setting permission groups' access levels to resource environments, which ensures that only certain groups can operate on production data.
Learn more about resource environments.
User attributes
Often, information about Retool users exists in systems outside of Retool, but is necessary to determine the data a user is allowed to access. User attributes allow you to set arbitrary metadata on the Retool user.
You can reference user attributes in Retool apps through JavaScript: you can hide and show data and app elements, as well as control custom behavior. You can also use them in queries, which makes it straightforward to set up row-level security in Retool.
Queries
To ensure users can only see data that is relevant to them, use query spoofing prevention. This ensures that any query referencing attributes on the current user cannot be modified to return other data.
Best practices
Many companies maintain access control services (in the form of APIs) that determine what data a user is allowed to see. Often these services rely on a user token sent from an identity provider upon login.
If you have OpenID SSO integrated with Retool, you can pass the JWT obtained from the login as a header to each request for this service. This ensures the Retool user is always authorized to make such requests, and your service would contain the necessary backend logic to determine what data to return to Retool.
If you don’t have OpenID SSO set up but have a separate authorization server, you can also define a custom authentication workflow. This lets your backend authenticate a user into your API.
App development and release process
Retool also provides controls to manage app development, reviews, and releases to users.
Source Control
Source Control allows organizations to manage changes to their Retool apps using pull requests on remote source control management (SCM) providers, such as GitHub and GitLab. Instead of making changes directly to an application, changes are made on a separate branch.
Protected apps are not modified until changes are reviewed and merged in the source control provider (e.g., in GitHub). This workflow mirrors a typical software development lifecycle, in which no engineer can push code directly to the main branch.
Source Control enables users to sync apps across multiple Retool instances and Spaces. If you have VPC isolation between non-production and production instances, a common approach is to configure your production instance of Retool as read-only, pulling changes from a central repository. Development happens on branches in a development instance, and once changes are reviewed through pull requests and app preview branches, code is merged into the main branch.
Releases
Releases let you version and release app changes to your users. This method can also be used in conjunction with Source Control. Once a branch is merged into production, you can review it on production data before rolling out changes to users using versioned release.
Audit logs
On a Business or an Enterprise plan, Retool provides audit logs for user actions that happen in Retool. If you're self-hosting Retool, you have access to the underlying PostgreSQL database on which your Retool instance runs. You can connect it as a resource and build your own Retool app to display custom views of your audit logs.
Additionally, you can send audit log events from Retool to DataDog. See our guide for more details.
In self-hosted Retool, all audit logs stream to stdout, so you can set up an external service or sidecar that consumes them.
Usage analytics
If you're on the Enterprise plan, Usage Analytics allows you to understand adoption across your organization at scale. By default for self-hosted Retool, usage is aggregated across all instances using the same license key. Similarly, if you have multiple Spaces set up on an instance, you can view usage across all Spaces.