Multi-instance releases are now supported for apps built in the new app builder, in addition to classic apps and workflows. To enable multi-instance releases, navigate to Settings > Source control > Edit settings and turn on Enable multi-instance releases.

Organizations using Source Control can manage releases of protected apps, classic apps, and workflows across multiple deployment instances. This feature enables you to publish different release versions across instances, making it possible to test a newer version on staging or development instances before promoting to production.

Multi-instance releases work slightly differently for apps and classic apps. Learn more about the difference, or get started with multi-instance releases for apps.

Enterprise organizations can use access policies to define which data each group of users can read or write on a resource. Retool enforces access policies on every query that runs against the resource. A policy can grant access to whole tables, specific columns, or specific rows.

For example, you can use an access policy to restrict an EMEA group's access on a table to only the customer rows for their own region. Retool applies that restriction to every query the group runs against the resource, so it holds regardless of which app, query, or agent the request comes from.

One policy covers queries from apps, the query library, raw SQL, and agents. Workflow queries against an enforced resource are blocked, so account for any workflows using the resource before you turn enforcement on. Retool supports access policies on PostgreSQL resources.

Access policies are enabled by default on cloud instances. On self-hosted instances, navigate to Settings > Beta and toggle on the feature flag for Enforce data security using access policies. To create a policy:

1. Open a PostgreSQL resource and select the Access Enforcement tab.
2. Turn on Data access enforcement.
3. Create a policy, choose the groups and environments it covers, and define its rules.
4. Activate the policy, then click Save changes.

Turning on data access enforcement closes the resource by default in every resource environment. Access policies apply only to the resource environments you select, so grant broad access first and narrow it once your policies are in place. Refer to Configure access policies for more details.

Access policies operate by granting access, not denying access. Refer to Access policies and Data access enforcement for more information.

Admins on the Enterprise plan can now complete each step in the Get started section of the Overview page using guided step-by-step wizards instead of navigating through separate Settings pages to complete configuration.

You can now directly configure from the Overview page:

• SSO
• Resources
• Source control
• Spaces
• Permissions

The Get started section is aimed at providing a better onboarding experience for admins of new organizations, and will help identify what configurations still need to be set up for admins or existing organizations. For example, setting up spaces walks you through choosing custom spaces or a Dev/Staging/Prod environment split, naming and configuring each space, and optionally copying over your existing SSO settings, before creating every space at once.

The Overview page also includes an Action center that contains important notifications and pending join requests, suggested users, and seat upgrade requests, so admins can act on what needs attention, as well an at-a-glance overview of your organization stats, such as total users, apps, workflows, and AI credit usage.

Retool introduced several features to help Enterprise organizations manage AI token spend when using their own API key for AI resources.

Use the new Get BYOK AI token usage endpoint to measure the number of tokens consumed for each AI resource that uses your own key. You can view the number of tokens consumed by resource, user, and surface area.

In addition, you can also view BYOK AI token usage in Settings. Navigate to the Usage Analytics page, and click the AI tab. You can filter AI usage by model, user, and feature.

Learn more about credit and token monitoring.

For Enterprise organizations that use Source Control to protect apps, you can now use the app builder to check out a branch that you created outside of Retool. This enables you to transition your changes from a local development environment to the app builder. This can be useful for visually validating your changes in the preview canvas.

Retool now supports object roles—a new role type that grants groups Use, Edit, or Own access to specific apps, workflows, resources, and agents. Object roles are separate from organization roles, which control access to admin settings like billing and SSO.

When you create an object role, you set an access level for each object type and choose how the role applies:

• Universal access—The role applies to all current and future objects of that type across the organization.
• Individual access—Access is scoped to specific objects or folders, which you define when assigning the role to a group.

Object roles are assigned to groups from the Groups page. Once assigned, all members of the group inherit the role's permissions. You can view a group's or user's full object-level access from the Object permissions tab on their detail page in Settings.

Updates to organization roles​

As part of this launch, organization roles have been updated to cleanly separate admin settings access from object-level access. The Create Role button on the Roles & Permissions page is now a dropdown where you choose between creating an object role or an organization role. A filter control on the roles list lets you view all roles, object roles only, or organization roles only.

To get started:

• Object roles—Understand how object roles work, including universal vs. individual access and folder inheritance.
• Create an object role—Step-by-step instructions for creating and managing object roles.
• Organization roles—Updated UI for managing organization roles, including a new role type selector and filter controls on the Roles & Permissions page.
• Assign roles to groups—Assign object or organization roles to groups.

Admins can now use the Overview page in Settings to set up their Retool organization and respond to pending user requests.

The Get started section guides you through configuring the core areas of your organization, including single sign-on (SSO), resources, permissions, spaces, source control, and the Retool API.

Retool marks each step as complete once you configure it, and you can mark any step that does not apply as not relevant. The module is hidden once you complete the Get started steps.

The Overview also surfaces pending join requests and suggested users, so you can approve new members without leaving the page.

Source Control configuration now supports embedded expressions in sensitive credential fields, including access tokens, passwords, private keys, and SSH keys. This enables secure credential management using configuration variables and secrets.

Toggle the Template variables in Source Control config feature flag in Settings > Beta to enable this feature.

• On cloud and self-hosted instances, you can reference configuration variables:

  {{ environment.variables.MY_KEY_OR_TOKEN }}
  

• On self-hosted instances only, you can also reference secrets from secrets managers:

  {{ secrets.MY_SECRET.KEY }}
  

Embedded expression support is available for all Source Control git providers: GitHub, GitLab, Bitbucket, Azure Repos, and AWS CodeCommit. The UI includes field captions, autocomplete, and validation to help you use embedded expressions correctly.

Non-sensitive fields like repository names, branch names, and usernames do not yet support embedded expressions.

For Enterprise and Business plans, Retool now allows admins to control access to Assist and its Ask and Build modes. Organization admins can use roles and permissions to create roles and edit roles with one of the following permissions:

• Use Assist with Ask and Build mode
• Use Assist with Ask mode only
• No access to Assist

By default, all users have access to Assist and both Ask and Build mode through a preconfigured role. This role is called Assist Role or Editor, based on when your organization was created. Organization admins can edit these roles, or they can create new roles with more restrictive permissions.

This change is valuable for organizations that need to limit or prevent Assist usage to specific populations of users. For example, admins might wish to restrict Assist usage to user groups who do not have access to sensitive data or PII. Alternatively, admins could restrict access to all user groups except for a pilot group testing AI tools.

Multi-instance releases are now generally available to cloud instances and self-hosted instances on version 3.330 or later, with support for both apps and workflows.

Organizations using Source Control can manage releases of protected apps and workflows across multiple deployment instances. This feature enables you to publish different release versions across instances, making it easy to test newer versions on staging or development instances before promoting to production.