The tool names say “node” where the builder says step. They’re the same thing — a node is one step in the workflow.
How the assistant builds a workflow
Workflows are built one step at a time: pick a trigger, add a step, fill in its inputs, test it, then move on to the next. A step’s output can only be used once that step has been tested. Later steps usually need data from earlier ones, and those references only work after the earlier step has actually run. So the assistant tests as it builds rather than at the end — and every step needs a passing test, including final ones that nothing reads from. Testing a single step can have real effects. Most steps are tested with mock data by default. Some can only be tested for real, and testing one of those withworkflow_test_node makes a real call — sending the actual email, writing the actual row. workflow_test never does: it runs every step that would change data as a mock, and reports one that has no mock as untestable for you to test in the builder.
Creating and managing workflows
Publishing means enabling. A workflow does nothing until it’s published, no matter how complete it is. Unpublishing stops it without losing any work, so it’s a safe pause rather than a deletion.
Finding the right step type
Softr supports hundreds of trigger and action types. These tools let the assistant search them and read what a given type needs.workflow_get_dynamic_input_options fills in the dropdowns you would otherwise pick from by hand — which Slack channel, which Trello board, which AI model. Those options live in the connected tool rather than in Softr, so they are fetched while the workflow is being built.
See Trigger Types for what can start a workflow.
Building the steps
Every branch whose condition is true runs. There is no “else” path: a branch without a condition always runs, and a path meant for “otherwise” needs the opposite of the other paths’ conditions. The order of the branches is only visual, since the paths run in parallel.
Retries only cover temporary failures, such as rate limits, server errors, and timeouts. A step that fails because of its setup or its credentials fails straight away. Retry can’t be set on triggers, on control steps like branches, filters, waits and loops, or on steps inside a loop.
Testing
workflow_test tests the steps in order and keeps going when one fails, so one call shows the state of the whole workflow. It reuses a step’s saved sample unless an earlier step’s sample changed, so after editing a step that was already tested, test that step on its own. A workflow started by an app or a webhook has no test data until a call reaches it: workflow_test can send it sample events first, as long as the workflow is unpublished.
workflow_get_node_output without a specific step is the “is this finished?” check — it lists every step and whether it has been tested. Worth asking for before you publish.
Runs
These are the runs on the workflow’s Runs tab in Studio, so they are how an assistant finds out why a workflow failed. Only a published workflow records runs; tests are not runs. A finished run can still have failed steps, so look at the failed-step count, not just the status. Runs older than your plan’s log retention are not returned.