Skip to main content

Most workflow problems are data-flow problems

The trigger may be correct and the step may be valid, but the workflow can still fail if the wrong data is passed between steps. That is why working with data between steps is a core workflow skill.

Start from the trigger output

The trigger is usually the first source of data in the workflow. Before adding several downstream steps, understand:
  • what fields the trigger provides
  • which of those fields are actually useful
  • what later steps will need
This helps you avoid depending on data that is not reliable or necessary.

Reference previous step outputs deliberately

Every step should know where its input is coming from. For each step, ask:
  • which previous step produced this value
  • is that value always present
  • does the next step need the raw value or a cleaned-up version
That keeps the workflow easier to understand and easier to troubleshoot.

Pass only what the next step needs

A good workflow handoff is small and intentional. Try not to map every available field just because it exists. Pass the values that the next step actually needs to do its job. This keeps the workflow simpler and reduces confusion later.

Expect data shapes to change

Different steps may return data in different formats. That is especially common when:
  • an AI step rewrites or summarizes content
  • an HTTP request returns nested data
  • one app expects fields that another app does not use
Whenever the data shape changes, confirm the next step still knows how to use it.

Use templates and expressions carefully

Templates and expressions are useful for shaping values, combining fields, or formatting output for the next step. Start simple:
  • reference one field at a time
  • confirm the output shape during testing
  • only add more complex logic after the basic mapping works
Complex expressions are easier to manage once the base data flow is already stable.

Inspect real outputs during tests

The best way to understand workflow data is to inspect actual step outputs during tests and runs. Do not rely only on assumptions about what a step should return. Check what it actually returns in practice.

Keep the chain easy to explain

If you can describe the data flow in plain language, the workflow is usually in good shape. For example:
  • webhook sends lead details
  • AI step classifies the lead
  • Slack step sends the summary to sales
That is much healthier than a workflow where it is no longer clear which step created which value.