Enable fallback

Reference remote tasks, views, resources, and config variables from Studio locally.

By default, any task referenced by a view or another task must be registered when the studio starts up. Additionally, any resource or config variable utilized by a task or built-in must also be configured locally.

However, there are scenarios where you may not want to use local tasks or resources. For example, you may want to:

Execute a task or built-in against a real database.
More quickly test changes by not needing to boot local versions of your resources.
Locally test a task or view without having to configure the tasks they rely on.

In these cases, you can enable fallback behavior to indicate that you'd like to execute a task or reference a resource in a remote environment.

Local tasks, resources, and configs will always take precedence over remote ones, even if a fallback is enabled.

Enabling fallback

To use fallback, open the Studio settings by clicking the gear icon in the bottom left of Studio. Then, make sure the Enable fallback setting is toggled—this will allow remote execution in the currently selected environment:

While this option is enabled, you can switch the environment that remote execution occurs in by changing the selected environment in the Studio header:

To disable fallback behavior, simply toggle the setting off. Studio will remember the option you've selected, even if you restart the dev server.

Remote tasks

Tasks can be referenced from both Views and other tasks. If fallback is enabled and a task has not been registered with the studio locally, then that task will be executed remotely in the currently selected environment.

Any tasks executed remotely will have an indicator next to them:

The remote runs are considered to be Studio runs, and will not show up in the run history for that remote task page. However, they will still show up in the activity logs.

Note that local tasks can execute remote tasks, but not the other way around. Once a task has been executed remotely, any other tasks it executes will also be executed remotely even if those tasks have been registered locally.

For example, consider the following scenario:

The environment is set to production.
Tasks A and C are registered locally.
Tasks B and C are deployed remotely in production.
A executes B, and B executes C.

When A runs, the studio will detect that B is not registered locally, and attempt to execute B remotely. When B runs, C will also execute remotely, even though it was registered locally with the studio, since remote executions are not aware of any local tasks.

Remote resources

When executing a built-in or a task that uses a resource (e.g. a SQL or REST task), the studio will look for a locally configured resource. If not found and fallback is enabled, the studio will then look for it in that remote environment.

Remote resources will be shown alongside local resources in the resource tab of the studio:

Any built-ins that have been executed remotely will have an indicator, similar to remote tasks:

Remote config variables

If executing a task that uses config variables, the studio will look for those configs variables in the dev config file. If fallback is enabled, the studio will look in that remote environment if it doesn't find the given config variable in the dev config file.

Remote config variables will be shown alongside local config variables in the config variables tab of the studio:

Restrict fallback usage

In some cases, you may want to entirely disallow fallback behavior for a specific environment. For example, you may wish to prevent a user from accidentally executing a task in your Production environment from Studio. To disallow fallback, simply toggle the Allow remote execution from Studio setting off for that environment from the environment settings page:

When this toggle is set to off, the Enable fallback setting in Studio will automatically be set to off for that environment, and users will not be able to enable it.