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.

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.