Workflows
Every step and trigger: conditions, loops, tables, calls, end.
Event trigger: what a workflow starts with
Every workflow starts at a trigger. The Event trigger starts the workflow when a request comes in: through an endpoint of your API, from another workflow, or when you click Run. Because you have no real request yet while building, you give the trigger sample data: you try the workflow with it, and every field in it is a variable the next steps can use.
Schedule (cron): a workflow at fixed times
Not every workflow waits for a request. A weekly overview on Monday morning, a check every quarter of an hour, a clean-up every night: for that you start the workflow with a Schedule instead of an Event trigger. Flow then starts it by itself, at the times you set, even when nobody is signed in.
If / Else: one rule, two ways
With If / Else you let the workflow choose. You write down one rule (which field, which comparison, which value) and connect the two exits: Yes when the rule holds, No when it does not. Then you read the workflow back in plain language, the way a colleague would explain it, and compare with another field instead of a fixed value.
Transform data: make fields and calculate
Transform data puts new fields into the workflow's data: text with {{field}} in it, or a calculation that starts with =. You use it to get data into the shape the next step or the caller expects: compose a description, calculate VAT, rename a field.
Loop: repeat for every item
An order has lines, an export has rows, an API returns a list. With a Loop you run the same steps for every item in such a list. What a step inside the loop changes is kept for the next pass: that is how you add up or keep track of what you came across.
End: finish on purpose
Without End, a workflow stops after its last step and returns all the data it collected on the way. With an End step you decide how it ends: successful, with exactly the result you choose, or failed, with a reason everyone reads back on the run.
Table: look up rows
With the Table step a workflow works with the data in your Flow tables. Look up rows fetches the rows that meet your conditions, sorted the way you want, and passes them on as a list. A next step carries on with it: a loop per row, an answer to the caller, a message.
Table: add a row
A sign-up, an order, a report: what comes in you often want to keep. The Table step with Add one row writes a new row into a Flow table. Per column you say what goes in, usually a field from the request. Flow checks the row against the columns: a required field that is missing or text in a number column stops the step.
Human review: wait for approval
Some decisions you do not leave to a workflow: a large discount, a refund, an exception. With the Human review step the workflow pauses until someone approves or rejects in the Inbox, with an explanation that goes into the audit trail. After approval the workflow continues where it was; after rejection it stops.
Notification: a message for a team
With Notification a workflow composes a message for a team or channel, with data from the workflow in it. Without a connected messaging system it is a preview: Flow shows what would be sent, but sends nothing. That way you test the content safely; to really send, you use the steps of a connector, such as Teams or Slack.
Email: compose a message
The Email step composes an email: to whom, the subject and the text, with data from the workflow. Flow checks that the address is valid and that the subject and text are there. This step sends nothing itself: you see the draft, and a connector (such as Microsoft 365) really sends it. That way you can polish the text without anything going out.
To connect: a step for later
Sometimes you design a workflow before every system is connected: OneDrive, Teams or the CRM comes next month. With To connect you put that step in already. It shows what it would do and what it would pass on, but changes nothing. That way you test the whole workflow now, and replace the step as soon as the connection is there.
Loop: repeat while a condition holds
Sometimes you do not know beforehand how often something must happen: an API that answers page by page, an attempt you repeat until it works. Then you set the Loop to While a condition holds. The condition is checked before every pass; a step inside the loop must eventually make it false.
Stop the loop and Next item
Inside a loop you sometimes do not want to finish everything. With Next item (continue) you skip the rest of this pass and go on with the next item. With Stop the loop (break) you stop altogether: the workflow continues after the loop. Both only exist inside a loop, usually after an If / Else. Here you look for the first product that is sold out.
Table: update a row
Updating a row always goes by id: that way Flow knows for sure which row you mean. Usually you do not know the id, but you do know something else, such as an invoice number. Then you look the row up first and update the row you found. Here you mark an invoice as paid.
Table: delete a row
Delete a row removes one row, by id. As with updating, you first look the row up by something you do know. Deleting is final: the table keeps track of who changed what, but the row itself is gone. Here you remove a cancellation from the list of participants.
In-memory table and Add row
An In-memory table exists only during the run. You give it fixed columns with a type, fill it from a list and get clean JSON back: every row is checked, so text in a number column stands out straight away. With Add row you then add single rows. Handy for an answer to a caller or an export.
HTTP request: call an API
With HTTP request a workflow calls another API: a supplier, a web shop, an internal system. Through a connection the address and the key stay in one place, on the server; in the step you only put the path. The answer gets a name, so the next steps can get at it.
Call workflow: reuse a workflow
What you need more often, you build once: a VAT calculation, a customer check, a standard message. With Call workflow you use such a workflow as one step in another. It runs inside the same run, gets the input you pass, and what it returns with its API response comes back under the name you choose.
API response: what the caller gets back
When a workflow sits behind an endpoint, the API response step decides what the caller gets back: the HTTP status and the body, with data from the workflow. Without an API response the caller gets everything the workflow collected. You build the answer, publish the workflow as an endpoint and call it the way a consumer does.
App action: a write action as a draft
App action records what the workflow would want to do in a system of record (create an order, update a customer), without really doing it. You design and test the workflow end to end; the step shows which action is planned on which connection. For the real call you later replace it with an HTTP request or a building block.
Work queue: work through row by row
A work queue works through the open rows of a Flow table one by one, the way a robot works through its in-tray. Per row it sets the status to busy, runs the steps inside the queue and sets the row to done, or to failed with the reason. One failed row does not hold up the rest; people see and fix it in the table itself.
Show widget: data as a card
A chat widget is a card, table or chart that appears in the chat. With Show widget a workflow fills such a widget with its own data. When an AI Colleague calls the workflow, the user sees the card in the chat instead of a wall of text. In the Studio you see the result straight away under the output.
Building block: use a published block
A building block is a separate, tested piece of work: an HTTP call, a bit of Python, an AI prompt or, as here, a pattern that pulls order numbers out of text. With the Building block step you use a published version in your workflow. You link every input to data from the workflow; the result gets a name.
Validate data: check first, then process
Validate data comes from a plugin: an extension your administrator adds to Flow, and that sits in the library like any other step. You write per field which type it must have. If everything is right, the workflow continues through the top exit; if something is missing or a type is wrong, through the bottom one, with the errors attached.