Skip to main content

Steps

Steps are the fundamental building blocks of Stepflow workflows. Each step executes a specific component and produces output that can be used by subsequent steps.

The following example is a minimal step -- a name for referencing it's results, the component to execute, and a description of the input to the component.

Minimal Step
  - id: step_name
    component: /path/to/component
    input:
      a: 1
      b: { $input: "input_value" }
      c: { $step: previous_step, path: "result_field" }

As you can see, inputs can reference flow inputs, step outputs, or literal values. See Expressions for more details on how these references can be created.

Skipping Steps​

Steps may optionally define a skip condition which determines whether the step should be executed or skipped. This should be an expression that evaluates to a boolean value.

warning

If a step is skipped, any later steps that reference it will be skipped by default. See Control Flow for more details on control flow and how to handle skipped steps.

Error Handling​

By default, an error in a step causes a failure that terminates the entire workflow. However, steps can specify on_error to configure different error handling.

Error Handling with Default Output
steps:
  - id: risky_operation
    component: /external/api_call
    on_error:
      action: continue
      default_output:
        result: "fallback_value"
        status: "error_handled"
    input:
      endpoint: "https://api.example.com"
Error Handling with Retry
steps:
  - id: flaky_api_call
    component: /external/api
    onError:
      action: retry
      maxRetries: 5    # default: 3
    input:
      url: "https://api.example.com"

Error Action​

The action may be one of the following:

  • fail (default): Stop workflow execution
  • useDefault: Use defaultValue and mark step as successful
  • retry: Retry component errors within the step up to maxRetries times (default: 3)
note

When using action: useDefault, the defaultValue must be set and produce a value that conforms to the component's output schema. The default output may be an expression that references earlier steps.

note

The retry action applies to component errors -- cases where the component ran and returned an error. Transport failures (subprocess crashes, network timeouts, connection failures) are retried automatically by the orchestrator independently of onError and are controlled via retry in the orchestrator configuration.

See Control Flow for more details on error handling in steps.

Next Steps​

  • For more information on available components and creating your own, see Components
  • For more details on how steps are executed, see Control Flow