A step below another one can only offer you fields it knows about. Testing is how those fields get discovered, which makes it part of building rather than an optional check.
Outcome
Every step is fully configured, and the steps below know what fields to expect.
Add and arrange steps
Click an Add step placeholder at the end of a path to extend it. Each open conditional branch has its own placeholder. To insert a step between two existing steps, click the + on their connection; the builder reconnects the steps for you.
Cards arrange themselves as the workflow changes. Use Fit workflow to see the whole graph, and pan or zoom to explore it. Click a card to configure it. For parallel steps, right-click a step and choose the corresponding action. Use On error to create a fault branch or connect to an existing step. Undo and Redo restore graph edits and arrange the restored steps automatically.
When deleting a step with children, choose Just this step (the default) to move its children up on the same incoming path, or delete the step and its entire downstream path. If the incoming path cannot be preserved, disconnected children are also removed. When deleting a conditional, choose a branch to keep or None — delete all branches (the default). The kept branch takes the conditional's place. Steps with another surviving parent remain connected. Undo restores the deleted steps and their original connections.
1. Fill in the step
Click the step to open the inspector. Configuration holds the step's own settings; what it asks for depends on the type.
An HTTP Request step, the most common starting point, asks for:
| Field | Notes |
|---|---|
| Connector | Optional. Only shown when your organization has outbound HTTP connectors. Picking one injects its credentials at run time. |
| Method | GET, POST, PUT, PATCH, or DELETE. Defaults to GET. |
| URL | Required. |
| Query Params / Headers | Key-and-value rows, added one at a time. |
| Body | JSON or Raw, with {{field}} template variables. |
The step card clears its warning as soon as the required fields are present.
2. Test it and discover the fields
Press Test step in the inspector header, or open the Test section and press Run test. Hodoflow issues the step's request once, immediately, and reads the shape of the response.
A success shows the response and, under Schema, the field paths it found.
Nested objects are flattened with dots, so a response like
{"base": "USD", "rates": {"EUR": 0.86}} yields base and rates.EUR.
HTTP Request and API Request steps can both be tested. An API Request step's request is rebuilt from the operation it is bound to and the parameters you have filled in, so what you test is always what is on screen — not what was saved last.
Three things to expect:
- The call really happens. The other end sees it, and anything it does in response is done. This matters for an operation that creates or changes something.
- A test sends the connector's credentials, the same ones a run would. An API Request step inherits them from its API Spec; an HTTP Request step uses whichever connector you picked.
- A test creates no run and stores nothing. It will not appear in Monitor.
The discovered fields are not written until you press Save, which is why the toolbar shows Unsaved changes after a successful test.
Checkpoint: the inspector lists the field paths you expect, and the step's card no longer counts toward invalid nodes.
A webhook trigger is sampled its own way: it has Refresh Schema — see Receive webhooks.
Testing a step that uses fields from an earlier step
A step whose settings contain {{field}} references has nothing to resolve them
against outside a real run, so the Test section asks you for a stand-in
value for each one — listed by the path it refers to, like webhook.id.
Fill in all of them. A reference left blank refuses the test rather than sending
an empty value: /orders/{{webhook.id}} with nothing to put in it is a request
to a different URL, and its response would be reported as this step's and
offered to every step below as its fields.
Because the request is real, a stand-in that looks like a real id will act on real data at the other end. Use one you are willing to have acted on.
Stand-ins are scaffolding. They are not part of the step, are never saved, and stay only until you reload.
3. Re-sample a source that has drifted
When a source's configuration changes after it was last sampled, a banner appears:
A source's configuration changed since it was last sampled. Existing mappings still save, but this workflow can't be activated until you re-sample.
Each affected source gets its own Re-sample button. Mappings keep saving throughout — only activation is gated — so drift never costs you work in progress.
Checkpoint: the banner is gone, and Activate is no longer refused with Data schema is stale.
Running a step once per item
HTTP Request, API Request, Data Transform, and Subflow each get an Iteration section. Leave Mode on Run once with the whole payload and the step behaves normally. Switch it to Run once per item and you get:
- For each item in — which list to walk. Every step above this one that
hands down a list of records is offered here; pick one. If there is exactly
one, switching the mode on picks it for you. Each element is available to
formulas as
item, so a field of it readsitem.total.- A list held inside one record — a
stationslist on a step whose output is a single record — is not one of those, so it goes under Walk a different list inside a step's output asfetch.stations.
- A list held inside one record — a
- When an item fails — Fail the run, or Skip and count, which attempts every element and lets the step succeed on the rest.
- Advanced — how many items run at once (up to 25), a delay between them (up to 60 seconds), and a Max items ceiling that refuses the step before any item runs.
Common problems
Test step is greyed out. An HTTP Request step has no URL yet, or an API Request step is not bound to an operation yet.
Run test is greyed out and there are boxes above it. One of the {{field}}
references has no stand-in value. Fill in every box.
It says a required parameter is not filled in. That is the step's own Parameters, not a stand-in — no test value substitutes for it. Fill it in under Configuration and test again.
The test returns 401 or 403. The connector's credentials went with the
request, so the credential itself is being rejected — check it under Service
Accounts rather than assuming the run will behave differently.
No fields were discovered from a successful response. The response was not a JSON object or an array of objects — plain text and XML bodies produce no field list.
The fields I discovered vanished. They are only written on save. Press Save after testing.
Activation says a step "is not fully configured". The message names the step and the reason. Every reason is listed on Activation errors.