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.

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.

Retool recently made changes that make it easier to review changes in source control. Retool now separates system-generated updates related to version upgrades into their own migration commit, so your pull requests are cleaner and easier to understand.

This feature is generally available on Retool Cloud. It is available in private beta to Self-hosted Retool organizations on edge version 3.203.0-edge or later, and will be generally available in an upcoming stable release. Self-hosted Retool organizations can reach out to support to enable this feature.

What's new​

Instead of bundling migration changes with user changes, they now appear in a dedicated commit.

No setup needed—this happens automatically when you make commits.

Improvements to source control on Workflows are now generally available on Self-hosted Retool 3.200.0-edge and in the upcoming stable release. The following features are now supported for all users on Enterprise plans:

Retool made several improvements to the usage of Source Control with Retool Workflows. The following features are now supported on Enterprise plans:

• Branched changes. You can now make changes to workflows using branches. Previously, all Source Control changes on workflows were branchless.
• Multi-element branching. You can make edits to workflows on the same branch as edits to apps, modules, and Query Library queries.
• Collaborative branches. Multiple users can commit changes and merge pull requests on collaborative branches.

The backend runtime in self-hosted Retool 3.163 and later has been upgraded to use Node.js v20.18. This change may result in memory and CPU usage of containers to increase. Without sufficient resources, this could impact the performance of Retool Workflows. If necessary, you can increase the memory limits for workflows using the WORKFLOW_MEMORY_LIMIT_MBS environment variable.

Multi-step functions are now generally available in Retool Workflows on Retool Cloud and on self-hosted organizations. They operate as self-contained workflows with optional parameters.

Multi-step functions improve the Workflows experience in several key areas:

• Isolating complex operations with many steps.
• Enabling nested looping, replacing the need for multiple subsequent Loop blocks operating on the same piece of data.
• Eliminating the need to call a workflow from within another, therefore decreasing the number of billable workflow runs.
• Enabling builders to reuse blocks of code within a single workflow.

You can now connect your organization to Sentry and Datadog for workflow error monitoring and event logging.

To set up error reporting, go to the Settings and navigate to Configuration > Observability. Enter your Sentry and Datadog credentials to emit workflow errors and run events to either or both providers.

Connecting to external observability providers is especially useful for your organization if:

• You have a high volume of workflow runs that your organization would prefer to monitor systematically, outside of the workflows run panel UI.
• Your organization is on Retool Cloud and you want to retain a record of workflow run events beyond the 90 day retention period.

When publishing your workflows, you can now choose to publish any changes to child workflows. This update streamlines workflow publishing by eliminating the need to manage releases separately. If you make a change to a referenced workflow, these changes are automatically detected when publishing the parent.

Retool recently made a series of improvements to the Run panel and other mechanisms that are commonly used to debug workflows. These changes include:

• Added filtering historical runs based on timestamp and workflow run ID in the Run panel.
• Added searching logs by block name in the Run panel.
• Added filtering blocks by type in the Run panel.
• Moved the Use as Example JSON button to the top of the Data tab.
• Added the ability to download JSON data from the JSON tab of block outpus or from the JSON tab of the Run panel.
• Added workflowRunContext to the Input tab of block outputs.
• Added endedAtEpochMs to workflowRunContext in the Input tab of block outputs.

To take advantage of these improvements, use the following best practices:

• Be sure to reference the workflow Run ID and the time that the workflow concluded in the body of your global error handler with workflowContext.currentRun.workflowRunId and workflowContext.lastRun.endedAtEpochMs. You can also emit both properties by default by connecting your Retool organization to Datadoog or Sentry. Having the workflowRunId and timestamp handy at debug time will allow you to quickly filter workflow runs to the errored workflow run.
• Name all of your blocks descriptively to make them easy to search for in the run panel.
• Reproduce workflow errors manually by using copied block JSON from the run panel as an input to downstream blocks.