Launching workflows

What the Launchpad is for

When you publish a workflow you get a version: a fixed snapshot. A version doesn't serve any traffic by itself. In the Launchpad you configure a version for an environment, such as Production or Staging, and that makes it a live instance that real requests reach.

So there are three things to keep apart:

• A version is a snapshot made when you publish. Publishing never changes anything that is live.
• An environment is where an instance runs. A workflow has at most one live instance per environment.
• An instance is a version configured for one environment, with that environment's variable values.

The Launchpad list

The Launchpad page lists each published workflow with its latest version. In the list you see its Name, Version, Status and when it was Published; the grid shows cards instead. A workflow with at least one live instance is marked Live, otherwise it shows Not live. Search published workflows… filters by name or description. Select a workflow to open its Launchpad.

If nothing is listed, publish a workflow from the Workflows page first.

A workflow's Launchpad

The page shows, from top to bottom:

• Live Instances: one card per environment where the workflow is live, chosen from a dropdown. Each shows the environment, the version it runs, whether it is the Default, and whether it is Active or Paused, along with when it was deployed and last updated.
• Versions: every published version, newest selected first. A version running anywhere is marked Live, and lists the environments it runs in. This is about where it runs, not whether it is the latest.
• Routes and Release Notes for the selected version. Routes show each route's endpoint, methods, steps and whether it needs authentication. Release notes describe what changed since the previous version.

Launching a workflow

1. Select the version in the Versions list, then select Configure. (The first time, with no live instance, Configure is the main button. After that, use the one above the Live Instances card.)
2. In the Launch Workflow dialog, choose the Environment, or select + New to create one. A new environment is created and deployed to when you finish.
3. Variables: set each variable's value for this environment. Connection variables pick from your connections. Secure strings take a password field, and leaving one blank keeps the current value when you are reconfiguring. Revert to default puts a variable back to the workflow's own default. Required variables must be filled in.
4. Route Authentication: shows, for each route, whether authentication is required and how. This step is read-only. The secret itself is a variable you set in step 3.
5. Review: check the workflow, version, environment and variables. It tells you whether this deploys a new live instance or reconfigures the existing one.
6. Select Launch. Once the instance exists the button reads Save Changes.

If you open Configure from the workflow editor, Go to Launchpad takes you here afterwards.

Reconfiguring and upgrading an instance

To change an instance, select Configure and choose its environment. The dialog switches to Reconfigure Instance with the values it has now.

To move an instance to a different version, first select that version in the Versions list, then Configure and save. A Version Change Detected warning confirms the instance will switch from the version it runs now to the one you selected. This works in either direction, so it is also how you go back to an older version.

Pause, default and delete

On an instance's card:

• Pause stops it serving requests, and Activate turns it back on. The instance and its settings are kept.
• Set as Default makes this environment the one used when a request doesn't name an environment. Requests without the X-REQUEST-ENVIRONMENT-ID header will go to this instance instead, so check that your callers expect that before confirming.
• View Variables lists the variables configured for the instance, with their names and types. Values aren't shown.
• Delete removes the live instance after you confirm, and it can't be undone. The published version stays, so you can launch it again.

Calling and testing an instance

API Endpoints on an instance's card explains how to call it. Choose a route and how the store is identified (Store ID in the URL, Store ID in a header, or a Hook URL that needs no auth headers), copy the URL or a ready-made cURL command, and use Send to try the request from your browser, with path and query parameters, headers and a JSON body. Requests to a non-default environment include an X-REQUEST-ENVIRONMENT-ID header, shown in the dialog. The default environment can be reached without it.

Rolling back

Rollback to this version replaces your current draft in the editor with a published version's content. It does not change anything that is live. Open the workflow in the editor to review it, and publish again if you want that version live. Anything unpublished in the draft is lost, so the dialog asks you to confirm.

Environments

Environments are created from the Launchpad dialog, or on the Environments page, where you can also rename them and choose the default. An environment can't be deleted while any workflow is still live in it, so delete those instances first. See Environments.