Steps v2

A Step is one unit in a Workflow. It either invokes an exact Node Method or represents a nested control flow scope.

Root Steps are stored in order under the Workflow's Steps list. Some steps, like For Each, contained nested Steps.

Fields

Field	Purpose
Name	Workflow-visible Step identity used by Expressions, logs, state, and designer relationships.
Description	Optional explanation of the Step's business purpose.
Node	Exact Node descriptor in <name>@<version> form.
Method	Exact Method display name from that Node version.
TemplateKey	Designer metadata identifying the template used to create the Step. It is not executed by the runtime.
Parameters	Input values and mappings supplied to the Method.
Returns	Output envelope exposed by the Method.
Steps	Child Steps or control-flow scopes owned by this Step.

Names

Use a concise, unique camelCase Name, such as getCustomer or writeInvoice. The name becomes part of every Expression that consumes the Step, so name it for the business action rather than its position.

Step names must be unique for unambiguous references. The designer updates references when you rename a Step through its supported controls. If you edit YAML manually, update every Expression that uses the old name.

Use Description when the purpose, side effect, or reason for a Step is not obvious from its name and Method. Do not use it to repeat the Method label.

Node and Method

An executable Step requires Node and Method:

- Name: getCustomer
  Node: crm@1.2.3
  Method: GetCustomer

Parameters

Step Parameters are target-side assignments. Use a literal Value or an Expression that consumes a Workflow Parameter or earlier Return:

Parameters:
  CustomerId:
    Type: string
    Expression: "{.customerId}"

Include required Parameters from the Method contract. Optional and conditional Parameters should follow the discovered contract and chosen template. A connectionKey Parameter must use an exact compatible Connection ID selected in Console or through an authorized selection tool.

Returns

Step Returns preserve the Method's published output envelope:

Returns:
  Customer:
    Type: object
    Properties:
      id:
        Type: string
      name:
        Type: string

Map from the Return on a consuming Property, such as {getCustomer.Customer.name}. Do not rename or flatten the producing Step's Returns to make a downstream mapping shorter.

Order and references

A Step can reference Workflow Parameters and Returns from earlier available Steps. Forward references are invalid. In a nested scope, an Expression must also respect the values exposed by that scope and its ancestors.

Nested and control-flow Steps

A Node Method can own nested Steps for looping, branching, error handling, or another control-flow behavior. The parent invokes the control-flow Method. Its child entries can include named placeholder scopes created by the binder, such as branch or body containers.

An executable child Step has its own Node and Method. A placeholder container Step omits Node and Method and contains its executable entries under Steps. Flowgear reports an error if an ordinary executable Step omits Node/Method or a placeholder container supplies them. See Container Steps and scope for the exact If, ForEach, and TryCatch shapes.

Add the control-flow Step from Console or obtain its exact template and contract through Builder discovery.

Templates

A template can pre-populate the exact Step, Parameters, Returns, and nested structure required for a common operation. TemplateKey records which template created the Step but is not used a runtime.

Treat templates as starting shapes. Validate their Node version and Method in the current Site, then map the actual contract required by the Workflow. When a step has run, you can use Infer Schema to adjust the Parameter and Returns schemas to their discovered shapes.

Trigger Steps

The Runtime represents HTTP, MCP, schedule, and listener interfaces with trigger Steps.

HTTP, MCP and schedule trigger Steps are skipped when debugging Workflows. Listener steps will block until the listener condition is met even when debugging.

Sub-Workflow Steps

A Sub-Workflow Step calls a published Workflow by its WorkflowKey. Its Parameters and Returns mirror the selected child's published contract. At runtime, the latest revision of the Workflow in the target Environment is loaded..

See Call a Sub-Workflow and Refresh Sub-Workflow Properties.

See Workflow Properties for Property shapes and Workflow Parameters and Returns for the external Workflow contract.