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. 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.
• You use a cloud instance 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.

Retool no longer requires NsJail to use custom JavaScript libraries and custom Python libraries in workflows on Self-hosted Retool. If your team is unable to grant privileged container access, this change enables you to still use custom libraries.

You can now set Test Headers and Test Path Parameters in the Trigger block of your workflow. This enables you to test your webhook trigger without needing to manually call the endpoint.

You can reference the startTrigger.headers and startTrigger.pathParams properties in the rest of your workflow.

Test headers and path parameters are used only for manual runs. For actual runs triggered via webhook, real headers and parameters are used instead.

You can now set an Alias to create a custom URL path for your webhook trigger. The resulting webhook URL is formatted as https://{domain}/url/{alias}. For example: https://example.retool.com/url/test-webhook.

You can also configure your custom URL path to include dynamic path parameters. This allows you to capture variable data directly from the request path and pass it to the workflow as input.

For example, you could set Alias to /orders/:id/status. A user would send a request to https://example.retool.com/url/my-custom-alias/orders/12345/status. The path parameter :id is dynamically resolved to 12345, and this value is then passed to the workflow as part of the execution input.

Retool now supports the Login Attempted Retool Event, which triggers after a user authenticates and before the login process is complete. You can use Login Attempted to trigger a workflow and execute custom logic, such as modifying user data or querying external resources.

Choose to present users with an error message, or redirect them to an app or URL.

You can only attach one enabled parent workflow to this Retool Event. Retool recommends that this logic remain lightweight, because this workflow runs synchronously in the login flow and blocks users from accessing their Retool account until the workflow finishes.