Steps
Every step an automation can hold, and what each one is for.
Steps run left to right, and a step runs as soon as everything feeding it is ready. A step with two things arriving sees both.
What travels along the lines is rows, documents or links, depending on what produced them. Most steps understand rows only, so the canvas refuses a line that would hand a step something it cannot read, rather than letting the run discover it.
Sources
Where a run gets what it works on. A source has nothing feeding it: it sits alongside the trigger rather than after it, because the trigger says when and the source says what.
| Step | Reads |
|---|---|
| Dataset | Rows from your data library |
| Files | PDFs, images and spreadsheets, either uploaded with the run or kept in a folder |
| Web pages | Links to read |
| Input table | Rows people keep up to date in a dashboard |
Files is the one with two modes, and they behave differently. Pointed at a folder, it takes each document once and remembers which it has read, so nothing is processed twice and nothing is missed. Set to take what was sent with the run, it reads whatever somebody attached on the dashboard that started it.
Transforms
| Step | Does |
|---|---|
| Filter | Keeps only the rows you want |
| Deduplicate | Drops rows that repeat an earlier one |
| Columns | Keeps or drops columns |
| Limit | Takes the first or last few rows |
| Work out a column | A new column from the ones already there |
| Aggregate | Groups rows and totals them |
AI
One step, and it does whatever you write in its prompt: read a document into rows, judge each row, or write a summary.
Two settings change its shape more than the prompt does:
- Once per run, or once per item. Per item is a model call and a charge for every row or document, so it is capped. Per run sees everything at once.
- One result, or a list. A list becomes rows. One result becomes a single record the rest of the automation can read.
You can pick which model each AI step uses, and turn on web search for one that needs to look something up. Reading a document to text is cached on the bytes of the file, so asking again about a document you have already read does not pay to read it twice. Mapping that text into columns is not cached, because that is the part you change while you are getting it right.
Bringing two tables together
| Step | Does |
|---|---|
| Join | Matches two tables on a column |
| Union | Stacks two tables on top of each other |
A union where the two sides spell one column differently makes two half-blank columns rather than one, so check the names match. A join keeps every match, so one row on the left matching three on the right is three rows out.
Flow
| Step | Does |
|---|---|
| If | Two ways out, one condition |
| Route | Several ways out, tried in order |
| Stop if empty | Ends the run when there is nothing to do |
Stop if empty is worth adding to anything that sends. Without it, a quiet night is an email with no rows in it, and people stop reading the ones that matter. With it, the run ends early and is recorded as a success rather than a failure.
Sending
| Step | Does |
|---|---|
| Sends the rows to people in your space | |
| Webhook | Posts the rows to a URL |
Email only ever reaches members of your space. Asked to email each customer their own row, it refuses at run time, so the place to notice is while you are building it. Leave the recipient blank and it goes to whoever set it up.
Both of these can act once per run or once per row, and both keep a watermark so a nightly send does not send yesterday's rows again. A run that sent some and then failed is reported as partly done rather than failed outright, because nothing sent can be taken back and a retry would send the first ones twice.
A webhook cannot be pointed at a private address. Flitch resolves the host before it calls, and refuses anything inside a private network, including a public name that resolves to one. A refusal never repeats the path, since a webhook address often carries a token there and your run history is readable by your whole space.
Output
Output is where the result is kept. It writes to a table in your data library, either a new one it makes on its first run or one you point it at, or to an input table so people can correct what the run produced.
Rows an automation extracts from documents carry which file they came from and when, so a dashboard can show one upload at a time.