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.

Use the Wait block to pause workflow execution for a specified amount of time. This block is useful for creating a single process that might need to take several hours, days, or weeks. For example, you could use the Wait block to:

• Grant a temporary access token, and revoke it after 24 hours.
• Send abandoned cart emails 1 hour after a customer leaves the website, and again after two days.
• Add a delay between several API calls in a loop to avoid hitting rate limits.

After the Wait block finishes executing, the workflow continues execution of the blocks downstream. Wait blocks only pause execution for blocks that are directly downstream, and they not do not affect blocks that are executed in parallel.

Workflow blocks, which enable you to trigger one workflow from another, now support two execution modes:

• Finished: The current workflow execution is paused until the triggered workflow run has completed.
• Queued: The current workflow execution continues and the triggered workflow run is queued. Both workflows may run simultaneously.

Query triggers, a new method for triggering workflows, are now available. Query triggers poll for messages from Amazon SQS and Kafka resources and execute a workflow's run for each message. These triggers are configurable to poll for messages on an interval or on a cron schedule.

Custom Python libraries for Retool Workflows is now available as a public beta. You can add one of the built-in Python libraries or provide a custom list of libraries and versions.

A new and improved version of the Loop Block is now available in beta. If you'd like to participate, complete this form to request access.

The new Loop Block features:

• Iteration-level timeout of up to 30 seconds when executing the entire workflow.
• Parallel, sequential, and batched execution modes with iteration delays
• Improved iteration-level error handling to allow subsequent iterations to run.
• Iteration metadata that is accessible in subsequent blocks.

Once enabled, any new Loop blocks added to workflows will use Loop block v2. Existing Loop blocks will continue to function as before.

You can now use configuration variables within workflows. Both values and secrets are supported and can be referenced using:

{{ retoolContext.configVars.YOUR_VAR_NAME }}