Changelog

For new Business and Enterprise plan organizations, the All Users group does not have universal access permissions by default. Admin users can add permissions to the All Users group as needed.

This change was made to simplify the process of creating custom groups, eliminating the need to remove permissions from the All Users group before creating more permissioned groups.

This change does not impact existing organizations, or organizations upgrading from Free or Team plans.

Retool added support within the IDE for merging changes from your default branch into your feature branch. This feature allows developers to keep their branches aligned with the default branch through guided, in-product flows, eliminating the need to switch to external tools like GitHub or GitLab.

When conflicts arise, Retool walks developers through a conflict resolution process entirely within the IDE, including validation checks to catch errors before completing the operation.

This change also eliminates the need for catch-up commits.

Beginning in version 3.251.0, a container running code-executor is required to run workflows and custom API authentication. Previously, these features could be run in a sandbox in the backend container. Retool's security team has become aware of a sandbox escape and will no longer be supporting sandboxing in the backend. For more information refer to the disclosure page.

Retool removed the preview release of Agents for self-hosted organizations since Agents is now in public beta with the 3.234.0 edge release and it will be available in the upcoming Q3 stable release. This preview release was intended for deployment into a non-production environment, and was created as a mechanism to allow Self-hosted organizations the opportunity to create agents prior to their availability in an edge or stable release.

When setting up Source Control with Bitbucket, you can now use a Bitbucket access token instead of an app password. Access tokens provide a more secure authentication method than app passwords.

Authentication using app passwords is still supported, but Retool recommends using access tokens instead.

If you use Source Control to protect a workflow, you can now create and publish releases for that workflow. This allows you to safely test and build changes without disruption. Previously, protected workflows were automatically versioned and published, and you could not publish a specific version.

Once you merge a change into the main branch, navigate to the Releases tab in the left-hand menu. In this tab, you can create, manage, and publish versions of the workflow. Refer to Version and publish workflows for more information.

Retool made several UI changes to the workflow IDE and updated some terminology to improve clarity of workflow releases. Instead of deploying a workflow release, you now publish the release instead.

The functionality remains the same and you continue to publish a workflow release for it to be live. This change was made to more closely align the app and workflow IDEs.

When you are ready to finalize your workflow changes, click Publish release in toolbar of the workflow IDE. This button was previously labeled Deploy.

Create, publish, and revert releases from the Releases tab in the left panel. This tab was previously labeled Deploy History. You can also navigate to the Releases tab using the button in the status bar of the IDE, which also displays the currently published release version.

You can now view which users and user groups have access to a workflow, resource, and agent. When on the listing page for one of these objects, click the ••• menu and select View access list. Use the tabs at the top of the list to show Users or Groups. The list shows the access level of each user or user group.

Resources display permissions on a per-environment basis if they are configured.

Access lists were already available for apps and app folders.

Retool Agents is now in public beta on Self-hosted Retool 3.234.0.

To enable Retool Agents in Self-hosted Retool 3.234.0 and later, the AGENTS_ENABLED environment variable must be set to true.

Modules now support typed data inputs. This change makes your modules more reliable by catching mismatched data types early.

Previously, modules offered only a Data input for passing in property values. Now, you can choose from the following options when configuring a module input:

• Any
• String
• Number
• Boolean
• Enum

Choose from String, Number, Boolean, or Enum for type validation on your module input. Selecting a Type enforces stricter validation rules and displays a warning if the input type does not match what you selected. You can also define additional characteristics about the input, such as options for Enum, and default values for all types.

If you set the Type to Any, Retool performs no validation on the module input.