Steps Explained: Actions, Filters, Transforms, and Delays

Steps are the building blocks

Once a trigger starts a workflow, its steps do the work. A step is a single node in your workflow's graph. Every step has:

• a step key — a unique identifier within the workflow (required), e.g. welcome_email;
• a type — one of action, filter, transform, or delay (defaults to action);
• an optional connector and action (for action steps);
• a configuration — the step's settings, including data mappings;
• a position — a number used for ordering;
• a depends_on list — the step keys that must complete before this step runs.

Because each step can depend on earlier steps, your workflow is a directed acyclic graph (DAG) rather than a straight line. That is what lets you branch, run steps in parallel stages, and gate whole branches behind a filter.

The four step types

Action An action does something in a connector — send_email (StretchMail), create_task (StretchTasks), add_tag (StretchCRM), record_payment (StretchBooks), schedule_post (StretchSocial), http_request (Webhook/HTTP), and so on. You pick the connector and its action, then map the action's inputs from the trigger and earlier steps. During a simulate run the action's resolved input is captured with no real side effect; in a live run the action is queued for dispatch.

Filter A filter is a gate. It evaluates one or more rules against the run's data; if the rules pass, execution continues; if they do not pass, the filter is skipped and — importantly — every step that depends on it (directly or transitively) is skipped too. Filters are how you say "only continue when the order total is over $100" or "only for VIP customers."

Transform A transform reshapes data without touching a connector — combining fields, renaming keys, formatting values — so later steps receive exactly the shape they need. Its resolved output is added to the run context for downstream steps to use.

Delay A delay pauses the branch before continuing — useful for spacing out a follow‑up email or waiting before a reminder. Filters, transforms, and delays are all provided by the Built‑in logic connector.

Dependencies and the DAG

The depends_on list is the heart of the graph. A step with an empty depends_on runs off the trigger. A step that lists ["welcome_email"] runs only after welcome_email completes. When you validate and plan a workflow, StretchAutomate performs a topological sort: it groups steps into ordered stages where each stage's steps have all their dependencies satisfied by earlier stages. Steps in the same stage can run together.

Because it is acyclic, a workflow cannot contain a dependency cycle (A depends on B and B depends on A). Validation catches cycles and other structural problems before you run.

Add a step, step by step

1. Open the workflow and choose Add step.
2. Enter a unique step key (kebab‑case is easy to reference, e.g. notify_owner).
3. Select the type. For an action, also pick the connector and action.
4. Fill in the configuration, mapping inputs from {{ trigger.* }} and {{ steps.<key>.* }}.
5. Set depends_on to the step keys that must run first (leave empty to run off the trigger).
6. Save. Re‑using an existing step key updates that step in place instead of adding a duplicate.

Realistic example

A workflow triggered by StretchShop order_created has four steps:

1. high_value — a filter that passes only when {{ trigger.total }} is above 500.
2. vip_tag — an action (StretchCRM tag_customer) that depends on high_value.
3. owner_task — an action (StretchTasks create_task) that also depends on high_value, telling an account manager to follow up.
4. thanks_delay then thanks_email — a delay followed by a StretchMail send_email, spacing a thank‑you a day later.

Because vip_tag and owner_task both depend on high_value, they land in the same stage and run together — but only if the filter passes. If the order is under 500, high_value is skipped and so is the entire branch beneath it.

Tips

• Give steps descriptive keys — you will type them into other steps' mappings and dependencies.
• Use filters early to gate expensive branches; skips propagate downward, so one filter can guard many steps.
• Model true parallelism by giving independent steps the same dependency — they will share a stage.
• Prefer a transform to cramming complex data juggling into an action's config; it keeps each step readable.

Troubleshooting

"A step_key is required." Every step needs a unique key. Provide one.

A step I expected to run was skipped. It (or a step it depends on) sits under a filter that did not pass. Check the filter's rules and the run's data in the ledger.

Validation reports an invalid graph. You likely have a dependency on a step key that doesn't exist, or a cycle. Fix the depends_on references and re‑validate.