Workflows

Workflows automate work in the background: something happens, and Softr responds by sending an email, updating a record, calling an API, or whatever else you need. These tools let an assistant build one for you — choosing a trigger, adding the steps, wiring them together, testing them, and turning the workflow on.

​

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 can have real effects. Some steps can be tested with mock data. Others can’t, and testing one makes a real call — sending the actual email, writing the actual row.

​

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. 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

​

Testing

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.