Building and Managing Workflows

What a workflow is

A workflow is a single automation: one trigger plus the ordered steps that run when it fires. Every workflow has a name, an optional description, a trigger type, a trigger configuration, a status, and a version number that increments each time you edit it. Workflows live in the Workflows tab, where you create them, open them for editing, change their status, run them, and archive them.

The workflow lifecycle

A workflow moves through four statuses:

• Draft — the starting state. Nothing fires automatically. Build and test here.
• Active — live. The workflow fires automatically whenever its trigger occurs.
• Paused — temporarily switched off without losing its definition. Re‑activate anytime.
• Archived — retired. Deleting a workflow archives it (a soft, reversible retirement) rather than destroying its history.

Status is the safety switch of StretchAutomate: an automation only runs on its own once it is Active.

Create a workflow

1. Open the Workflows tab and click New workflow.
2. Enter a name (required) — make it describe the outcome, e.g. Paid invoice → thank-you email. A workflow with no name is rejected.
3. Optionally add a description so teammates understand its purpose.
4. Choose a trigger type — Manual, Webhook, Schedule, or App event — and fill in the trigger config if the trigger needs details (for example, which connector event to listen for). See Workflow Triggers Explained for each type.
5. Save. The workflow is created as a Draft.

Add and order steps

Inside a workflow you assemble steps. Each step has a unique step key, a type (action, filter, transform, or delay), an optional connector and action, a configuration, a position (for ordering), and a depends_on list that defines which earlier steps must complete first. Together the steps form a directed graph. See Steps Explained for the details of each type, and Data Mapping and Templating for wiring data between them.

1. Open the workflow and add a step, giving it a clear step key such as thank_you_email.
2. Pick the type and, for actions, the connector and action.
3. Set depends_on to the step keys that must run first. Leave it empty to depend directly on the trigger.
4. Repeat for each step. Use position or dependencies to control order.

Step keys are unique within a workflow. Adding a step with an existing key updates that step rather than creating a duplicate — a convenient way to revise a step in place.

Edit, version, and change status

• Edit a workflow to change its name, description, trigger type, or trigger config. Every save increments the version so you always know the definition changed.
• Change status directly (Draft → Active, Active → Paused, etc.) from the workflow's status control.
• Delete a workflow to move it to Archived. The definition and run history are preserved, so this is reversible.

Publish vs. activate

You can flip a workflow to Active directly, but the safer path is Publish. Publishing first validates the graph; if validation fails, the workflow is not activated and you receive the validation errors. Only a valid workflow is published to Active. Use Publish when you want a guardrail against shipping a broken automation. (Publishing requires the StretchAutomate engine to be enabled — see The StretchAutomate Engine.)

Realistic example

A bookkeeper builds Paid invoice → thank-you email. They set the trigger type to App event listening for StretchBooks invoice_paid, then add one action step thank_you_email (StretchMail send_email) that greets the customer by name using data from the trigger. They keep it in Draft, simulate a paid‑invoice payload, confirm the ledger shows the right recipient and copy, then Publish — which validates the single‑step graph and switches it to Active. A week later they add a second step, tag_loyal_customer (StretchCRM add_tag), depending on the email step; the version increments to 2, they re‑simulate, and re‑publish.

Tips

• Name workflows by outcome (trigger → result) so the Workflows list reads like a table of contents.
• Build in Draft, prove it in simulate, then Publish. Never activate an untested workflow.
• Use Paused rather than archive when you are only stopping an automation temporarily — it keeps the workflow in easy reach.
• Watch the version number when collaborating; a jump means someone changed the definition.

Troubleshooting

"A workflow name is required." You tried to save without a name. Enter one and retry.

"Workflow status is invalid" / "trigger type is invalid." Status must be one of draft, active, paused, archived; trigger type must be one of manual, webhook, schedule, app_event. Pick a valid value.

Publish fails with a validation error. The graph did not pass validation — for example, a step depends on a key that does not exist. Open Validate & Plan, read the reported errors, fix them, and publish again.

I can't find a workflow I deleted. Deleting archives the workflow. Filter the Workflows list to Archived to recover it.