Workflows triggered by a schedule, a webhook, or a query, can now run as a service user. Service users for workflows are available on Business and Enterprise plans. Previously these runs defaulted to running as the first admin in your organization.

Select a permission group in the Triggers panel of the workflow IDE. Retool creates a service user for the group, and triggered workflows run as that service user. Only members of the group and admins can edit workflows running as a service user, and run logs are limited to people in the service user group.

Key features of this release include:

• Service users allow workflows run against resources with data access enforcement turned on. Scheduled and webhook-triggered workflows no longer need a separate unenforced resource. Grant the service user group access in your access policies.
• Service users do not count toward your user seats.
• Audit logs record actions that a service user performs under the existing event types, with the service user's ID as the actor.
• Source control includes a workflow's run identity in its YAML file. On deploy, Retool matches the service user by ID, then by group name.

If an admin deletes a service user group, workflows set to run as that group will fail until you choose a new group.

To get started, refer to Run a workflow as a service user. For details on how run identities work, refer to Service users for workflows.

Retool removed versions 1.0 and 2.0 of the Microsoft SQL integration. The removal is live on cloud instances. It reaches self-hosted instances in Retool 4.88 Edge and the first release of the next stable cut.

Apps, workflows, and queries that depend on Microsoft SQL resources still using version 1.0 or 2.0 stop working. This follows the deprecation announced in July.

What to do​

Update each affected resource to version 3.0:

1. Open the resource from the Resources page.
2. Change Connector version to Version 3.0.
3. Save your changes.

Version 3.0 accepts array values in query parameters, so you don't need to rewrite existing queries. If you haven't intentionally created a resource on an older integration version, your resource is likely already on version 3.0.

Admins on Enterprise plans can now set spend limits on AI usage using the new Spend Controls tab in the AI monitoring settings. On self-hosted instances, this page is named AI visibility.

Limits work for both Retool-managed keys (credits) and bring your own key (tokens). Set an organization-wide default user limit, then override it for specific users or groups. You can also set a limit on a model to cap its total usage across your organization. For each, you can set a Notify at limit, which sends notifications and lets usage continue, and a Block at limit, which blocks further usage. A user's effective limit is their own limit, then the highest limit among their groups, then the default. Model limits apply separately from user and group limits.

When a builder reaches a block limit, AI app building pauses and they can send a limit increase request to admins. Admins can review requests in the Spend Controls tab or from the Action center on the Overview page, then approve a higher limit or deny the request. Retool also sends email notifications when limits are reached.

Starting January 1, 2027, Retool is deprecating Retool Email for organizations on the Free plan. After this date, Free plan organizations can no longer use Retool Email to send emails from apps, workflows, or other automations.

Retool Email remains available to organizations on the Team, Business, and Enterprise plans.

Who is affected​

This change affects cloud-hosted organizations on the Free plan that use Retool Email. Organizations on paid plans are not affected.

As part of our continued efforts to keep Retool secure and reduce vulnerabilities, Retool is deprecating several preinstalled third-party libraries, such as jsonwebtoken, crypto-js, moment, and uuid, currently available in custom authentication JavaScript steps. Retool plans to remove these libraries from cloud and self-hosted instances in Q2 2027.

If your custom authentication steps use any of these libraries, you can migrate to Node.js built-in equivalents, such as crypto and Buffer, well ahead of the removal date. Migrating before then avoids any disruption to your authentication flows.

Only REST API, GraphQL, OpenAPI, and gRPC resources that use Custom Auth with a JavaScript step that loads a preinstalled library are affected. JavaScript steps that use Node.js built-in modules, such as crypto, continue to work without changes.

Who is affected​

Any customers who have resources that use Custom Auth as its authentication method and one of its JavaScript steps loads a preinstalled library. Custom authentication steps that only use Form (modal), API Request, or Define a variable steps aren't affected, and neither are JavaScript steps that don't call require().

Version 3.0 of the Microsoft SQL integration accepts array values in query parameters. Retool converts an array to a comma-separated string before passing it to SQL Server, which matches the behavior of version 1.0.

Retool previously documented this as a breaking change and recommended converting array values with .join(',') before using them with STRING_SPLIT. The restriction was broader than documented: it applied to any query parameter set to an array value, whether or not the query used STRING_SPLIT. Version 3.0 removes the restriction entirely, so queries that pass array values no longer need to be rewritten. Queries that already use .join(',') produce the same value and continue to work without changes.

This was the only known breaking change between version 1.0 and version 3.0. You can now update an existing Microsoft SQL resource from version 1.0 or version 2.0 to version 3.0 without changing your queries. Versions 1.0 and 2.0 are deprecated and will be removed, so Retool recommends updating any resource still using them.

Query parameters set to an object are not supported and cause the query to fail. Convert an object to a string before using it in a query, for example with JSON.stringify.

Retool is deprecating the dedicated BigID resource type.

Retool will remove the resource type in Q1 2027, after two quarterly Stable releases. After removal, BigID resources will stop working. Queries in apps and workflows that still point at those resources will fail. Cloud and self-hosted organizations will not have a BigID connection option after removal.

Organizations can keep querying BigID after removal by creating a REST API resource. Retool will not migrate BigID resources or their query references automatically.

1. Create a REST API resource. To use guided query creation, select Use an API spec and enter the specification URL https://sandbox.apps.mybigid.com/BigAPI.yaml or the BigAPI.yaml URL for your BigID instance, with the environment server variable set to your BigID hostname. Otherwise, select Manual queries and set the base URL to https://HOSTNAME/api/v1.
2. Set Authentication to Custom Auth. Add an API Request step that sends POST /api/v1/refresh-access-token with your BigID user token in the Authorization header. Add a Define a variable step named SYSTEM_TOKEN with value {{ http1.body.systemToken }}. Add an Authorization header on the resource that uses {{ SYSTEM_TOKEN }}. Enable Run this custom auth workflow without prompting the user. Configure a refresh auth workflow that repeats the exchange after a non-200 response. Generate the user token in the BigID UI and exchange it as described in BigID's token authentication.
3. Open each app, workflow, and Query Library query that uses the BigID resource. Change the query to use the new resource, then test it. If you used an API spec, select the same operation. Otherwise, recreate the request as method and path, such as GET /ds-connections. If the query editor shows an Authorization parameter, leave it empty.

Custom authentication is not supported in public apps. If you have a large number of BigID queries and need help finding them, contact Retool Support.

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 and self-hosted instances. To turn them off, navigate to Settings > Beta and toggle off 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. Turn on the policy's Status switch, 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 is deprecating versions 1.0 and 2.0 of the Microsoft SQL integration. Organizations with Microsoft SQL resources still using these versions must update their resource configuration to use version 3.0.

This deprecation will first take effect on cloud instances on August 24, 2026. It will then take effect in the next edge and stable releases that follow.

Version 3.0 has been available since February 2, 2026 for cloud instances and the 3.334 stable release. If you haven't intentionally created a resource on an older integration version, your resource is likely already on version 3.0 and requires no changes.

To upgrade an existing resource, open its settings from the Resources page, change Connector version to Version 3.0, and save your changes.

Versions 1.0 and 2.0 will be removed entirely from cloud instances in Q4 2026, followed by the subsequent edge and stable releases. After that, apps, workflows, and queries that depend on Microsoft SQL resources still using version 1.0 or 2.0 will stop working.