Flitch
Get Started
PricingIntegrationsDocsContact
Book Demo
Workflows

Your data, doing something about it

A dashboard tells you what happened. A workflow does the next part: it reads your tables, documents or web pages on a schedule or the moment something changes, works out what matters, and then writes a table, emails the people who need it, or posts it to whatever you use next.

Try for freeRead the docs

This is the real editor. Press Run.

Not a screenshot and not a video. Every step below runs on the example tables in your own browser, with the same code that runs them in your space. Add steps, draw lines, change the settings, run it again. Nothing is saved and nothing is sent anywhere.

Each evening it totals the picking log by paddock, compares each with its target, has a model note how it went, saves the table and emails the manager about anything behind.

Every workflow is two things

What starts it, and what it does. One thing starts it, and a button on a dashboard can sit alongside whichever you pick.

On a schedule

Every so many minutes, hours or days, counted from a time you choose so daily from 9am keeps landing on 9am instead of drifting.

When data refreshes

The moment a dataset you pick finishes updating. Better than a clock of its own for anything that depends on fresh data, because a clock runs at 9:05 against data refreshed at 9:00, or at 8:59 against yesterday's.

From a dashboard or app

Somebody presses a button or attaches a file on a page you built. The page shows each step as it happens, and reads the table the run filled when it finishes.

On a webhook

The workflow gets an address of its own, so anything that can post to a URL can start it. Set a secret header the far end has to send, and it is stored and never shown again.

Three more start a run, including when another workflow finishes and when one fails. The steps in between read, filter, join, run SQL, call a model, decide whether the rest happens, send, and keep the result. All of them are documented here.

Or describe it and have it built

Tell the assistant what the work is and it replies with a card showing the workflow it has in mind: every step, in order, and what each one still needs. Nothing exists until you apply it, and you can read the whole thing first.

What it will not do is invent an id. Which table a source reads, and which folder holds the files, are yours to pick, so those arrive blank and the card says so. The shape, the settings and the wording of an email come filled in.

What a run costs

Runs are billed in credits to the space that owns the workflow, and they show in your usage history as workflow runs.

  • The cost is what the steps do. Reading, filtering, joining and reshaping tables is close to nothing. A step that calls a model or reads a document is where the cost is, and one set to run once per row is capped for that reason.
  • Test runs are free of your allowance, and they write nothing: no rows added, no email sent, no webhook called, and a folder of documents left untouched so the real run still reads everything.
  • You can set a ceiling on what one workflow may spend. Past it, runs stop rather than carrying on quietly.
  • The Free plan holds 3 workflows and runs 1 at a time. Paid plans are unlimited in count and run 10 at once. Downgrading keeps the workflows you already have.
See pricing

Questions

What people ask before building one.

It reads a table from your library, a folder of documents, web pages, a public JSON endpoint, or rows people keep up to date in a dashboard. It filters, deduplicates, totals, joins, and runs SQL. It can call a model to read a document into rows, judge each row, or write a summary. It can decide whether the rest of the run happens at all. Then it writes a table, emails people in your space, posts to a URL, or builds a report.

No. Describe the work to the assistant and it proposes the whole workflow as a card you apply or ignore. Drawing it yourself is there because editing one by hand is how you get the details right, not because it is the only way in.

In credits, to the space that owns the workflow, whoever started the run. Reading and reshaping tables costs close to nothing; a step that calls a model is where the cost is. Test runs do not count against your allowance, and you can cap what one workflow may spend.

Yes, and this is the point of a test run. It reads everything for real and writes nothing: no rows, no email, no webhook, no documents marked as read. It also leaves the clock alone, so a test does not count as the night's run and does not move any watermark.

No. An email step reaches members of your own space and nobody else, and it refuses at run time if asked to send outside it. To reach people outside your space, post the rows to whatever you already use for that, which is what the webhook step is for.

That is the usual starting point. A workflow reads any dataset in your library, so anything you have already connected is available to it, and the trigger that fires when a dataset finishes refreshing means the work happens against fresh data rather than near it.

Build one this afternoon

Connect your data, describe the work, and read the workflow it proposes before anything runs.

Try for freeBook a demo