Skip to main content

Changelog

Updates, changes, and improvements at Retool.

Refer to the stable and edge release notes for detailed information about self-hosted releases.

29 posts tagged with "Resources"

Updates related to data sources and resources.

View All Tags

Deprecation of Retool Email for organizations on the Free plan

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.

Deprecation of preinstalled libraries in custom authentication JavaScript steps

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().

Deprecation of Windows Authentication for Microsoft SQL Server resources

As part of our continued efforts to keep Retool secure and reduce vulnerabilities, hardened images become the default for self-hosted images starting in Q2 2027. As a result, Retool is deprecating Windows Authentication for Microsoft SQL Server resources. This deprecation also applies to Kerberos authentication for Microsoft SQL Server, which relies on Windows Authentication.

Hardened images are intentionally minimal and don't include the additional third-party libraries and utilities that Windows Authentication relies on. Microsoft SQL Server resources with Connect using Windows Auth enabled will eventually stop working, so plan to migrate before your resources are affected.

Who is affected​

This change only affects self-hosted organizations with Microsoft SQL Server resources that have Connect using Windows Auth enabled.

Microsoft SQL integration version 3.0 restores support for array values

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.

Deprecation of the BigID resource type

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.

Access policies for PostgreSQL resources in public beta

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.

Deprecation of the Vertica resource type

Retool is deprecating the dedicated Vertica resource type.

Retool will remove the resource type in Q1 2027, after two quarterly Stable releases. After removal, Vertica resources will stop working. Queries in apps and workflows that still point at those resources will fail. Retool will no longer ship the Vertica JDBC driver. Cloud organizations will not have a Vertica connection option after removal.

Self-hosted organizations can keep querying Vertica after removal by creating a JDBC resource and adding a Vertica JDBC driver that you provide. Retool will not migrate Vertica resources or their query references automatically.

  1. Download the Vertica JDBC driver from Vertica.
  2. Add the .jar file to your self-hosted instance. Follow the JDBC configuration steps for JDBC_DIRECTORY_PATH.
  3. Create a JDBC resource with Driver name com.vertica.jdbc.Driver, connection string jdbc:vertica://HOSTNAME:5433/DATABASE?user=USERNAME&password=PASSWORD&DisableCopyLocal=true, and schema query select table_name, column_name, data_type, table_schema from columns. Include DisableCopyLocal=true on the connection string.
  4. Open each app and workflow query that uses the Vertica resource. Change the query to use the new JDBC resource, then test it.

JDBC resources do not support Retool-managed SSH tunnels. If your Vertica resource uses an SSH tunnel, or you have a large number of Vertica queries and need help finding them, contact Retool Support.

Deprecation of Microsoft SQL integration versions 1.0 and 2.0

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.

Microsoft SQL Server (Windows Authentication): unsupported ODBC connection params are now rejected

Retool now blocks Microsoft SQL Server resources that use Windows Authentication with custom ODBC connection parameters outside an approved allowlist. Previously, unsupported parameters were logged as warnings but still applied. They now cause resource setup to fail.

Who is affected​

Self-hosted deployments using Microsoft SQL Server resources with Connect using Windows Auth enabled and one or more custom entries in Connection options (or equivalent resource JSON) whose keys are not on the allowlist. Windows Authentication is not available on Retool Cloud.

How to check if you are affected before upgrading​

Search your Retool deployment logs (dbconnector / backend) for this exact string from the prior log-only release:

MSSQL Windows Auth ODBC connection string parameter not on allowlist

Each matching log line includes the parameter key (parameterKey in structured logs). Resources that logged this message will fail to connect or save after upgrading until those parameters are removed or replaced.

What you will see after upgrading​

Resource setup or test connection fails with an error like:

Unsupported MSSQL ODBC connection string parameter "<key>". Only a fixed set of ODBC attributes may be supplied via connection params.

Remediation​

  1. Open each affected MSSQL Windows Auth resource.
  2. Remove unsupported keys from paramsFromConnectionString.
  3. Use Retool's built-in resource fields where possible. For example, use SSL/TLS for encryption and certificate verification.
  4. If you need an ODBC attribute that is not listed below, contact Retool Support before upgrading.

Allowed paramsFromConnectionString keys​

ODBC attributeAlternate spellings accepted
APPapp
ApplicationIntentapplicationintent
ColumnEncryptioncolumnencryption
ConnectRetryCountconnectretrycount
ConnectRetryIntervalconnectretryinterval
Connect TimeoutConnectTimeout, connecttimeout
Failover_Partnerfailoverpartner
FailoverPartnerSPNfailoverpartnerspn
HostnameInCertificatehostnameincertificate
IpAddressPreferenceipaddresspreference
KeepAlivekeepalive
Languagelanguage
LoginTimeoutlogintimeout
MARS_Connectionmarsconnection
MultiSubnetFailovermultisubnetfailover
Packet SizePacketSize, packetsize
QueryLog_Onquerylogon
QueryLogTimequerylogtime
Regionalregional
ServerSPNserverspn, Server_SPN
Workstation IDWorkstationID, workstationid
WSIDwsid

Security-sensitive attributes (Driver, Encrypt, Trusted_Connection, credentials, Server, Database, and similar) are set by Retool and cannot be supplied via connection params.

Common parameters that are blocked​

  • Encryption and certificate trust settings such as Encrypt and TrustServerCertificate — use the resource SSL/TLS settings instead.
  • LoginRetryCount / LoginRetryInterval — use ConnectRetryCount / ConnectRetryInterval.
  • Credential keys such as Uid, Pwd, User, or Password.
  • Keys containing ; or crafted to inject additional ODBC attributes.

Deprecation of MongoDB 3.4 support

Retool is phasing out support for MongoDB Server version 3.4 and earlier. Organizations with an unsupported version of MongoDB Server connected to Retool must upgrade to MongoDB Server 3.6 or later.

  • For cloud organizations, support for MongoDB Server 3.4 and earlier has already been removed.
  • For self-hosted organizations, support for MongoDB Server 3.4 and earlier will be deprecated in the Q2 2026 stable release. It will be removed in the Q3 2026 stable release.

MongoDB Server 3.4 has been end of life (EOL) since January 2020. We recommend upgrading to a currently supported MongoDB release.