Updates, changes, and improvements at Retool.
Self-hosted organizations using Source Control to protect apps can opt into the public beta of multi-instance releases. This feature enables you to publish different release versions of apps across multiple deployment instances. This is particularly useful if you want to test a newer version of an app on a test instance first.
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.
Branch merging is currently rolling out in public beta on Retool Cloud and will be available on a subsequent edge version of Self-hosted Retool.
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.
With this change, users must manually create a new release in order for their latest changes to be reflected in the live version of the workflow.
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.
This change is currently rolling out on Retool Cloud and will be available in a subsequent edge release of Self-hosted Retool.
Organizations on the Business or Enterprise plan can now restrict users from accessing specific app pages with per-page permissions. When configuring a permission group, you can now also specify permissions for each page.
Per-page permissions are generally available on Retool Cloud and in on Self-hosted Retool versions 3.219.0 and later.
Retool has rolled out unique identifiers (UUID) for app pages. If you use Source Control, Retool recommends that you create a new branch with no changes and push it to Source Control. If you use Retool Cloud or self-hosted Retool 3.191-edge or later, Retool automatically creates a migration commit to add UUIDs to each page. Once you merge this commit, you can successfully configure per-page permissions on your protected app.
If you are working on more than one branch before the UUID addition in version 3.191-edge, Retool runs the migration on each of those branches, and the branches will end up with different UUIDs. Make sure add UUIDs only once, do not override the UUIDs on the main branch after adding them. Doing so results in the inability to set per-page permissions, because the IDs initially set on main are the ones that Retool will use.
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:
This feature was previously released as generally available on Retool Cloud and as private beta for Self-hosted organizations.
Retool can record user behavior and interactions with apps using Fullstory. When enabled, data about user interactions with apps are reported directly to Fullstory for you to review in detail. You can then analyze app analytics, evaluate impact, and review interactions with session replay. This integration is useful for monitoring user activity across different apps, and using advanced analytical tools like heatmaps and funnels to identify usage patterns, debug errors, and improve the overall user experience.
If your organization uses Source Control, Retool sometimes creates an automatic commit, called a catch-up commit, which keeps your branches up to date. If you want to ensure that developers in your organization retain complete control of changes within their feature branches, you can now disable catch-up commits using the following steps:
If you disable catch-up commits, users in your organization must manually, outside of Retool, rebase their branch and resolve conflicts in order to keep their branch up to date.
To avoid issues with catch-up commits and other merge control mechanisms, refer to Retool's Merge conflict prevention strategies.
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.