Workflows
A workflow is a trigger followed by steps, read top to bottom. Lodol keeps every version of it, runs it when it should, and records what each run did.
A workflow is the thing you build in Lodol: a trigger that says when it runs, followed by the steps it takes, in order. Anyone in your workspace can open it and read what it does, the way you'd read a short checklist.
Log Stripe payments
- Trigger
New Stripe payment
Stripe
Append row
Google Sheets · Revenue sheet
Send a message to a channel
Slack · #sales
A workflow reads top to bottom
Lodol runs the steps in the order they're listed. A step can only use what came before it: the trigger's event and the results of earlier steps. Sections change that order in two ways:
- An If section runs its steps only when its condition is true, with an optional Otherwise for when it isn't. See Make decisions.
- A Repeat section runs its steps once for each item in a list, a set number of times, or while something is true. See Repeat steps.
A run ends when it reaches the last step, when a step fails, or when someone stops it.
It starts in one of three ways
Every workflow starts the same way each time:
| Start | Runs when | Example |
|---|---|---|
| An app trigger | Something happens in a connected app | A new Stripe payment, a new Slack message, a new form response |
| A schedule | At the times you choose | Every 15 minutes, or every Monday at 9:00 |
| On demand | You, your code or another workflow starts it | A monthly report you run for one client at a time |
A workflow with a trigger or a schedule has to be turned on before it runs. Triggers and schedules covers all three.
Every change is a version
Each time a workflow is saved, Lodol keeps a new version. You can see what changed against the version that's running and roll back to any earlier one. Saving a change pauses a workflow that was on, until it's turned back on.
A workflow keeps the same ID across all its versions, so links to it, and code that runs it through the API, keep working after it's edited. Each run records which version it ran.
Private until you share it
A new workflow is visible only inside your workspace. To show one to someone outside it, make it public: anyone with its preview link can then see how it works, and you can make it private again at any time.
Who can do what
What each member can do depends on their role in the workspace. The built-in roles are Owner, Admin, Member and Viewer:
- Viewers can see workflows, runs and apps, but can't change anything. They suit people who only need to follow along.
- Running workflows, deleting them and deleting runs are separate permissions, Run workflows, Delete workflows and Delete runs, which a role may or may not include. Deleting a workflow keeps its runs; only Delete runs removes them.
- On the Pro and Enterprise plans you can create custom roles with exactly the permissions each member needs.
The same limits apply to anything acting for a member: an AI tool they connected and an API key they created can only do what their role allows.
How many run at once
Each plan sets how many workflows can be running at the same moment: 3 on Free, 10 on Builder and 40 on Pro, with a custom limit on Enterprise. A run you start through the API while you're at the limit is refused, so your code can retry; see Limits. Pricing has the current plans.
Next
Build with your AI tool
Connect Claude, ChatGPT, Cursor or any tool that supports MCP, then describe the automation you want. Your AI builds the workflow in Lodol, and Lodol runs it.
Triggers and schedules
A workflow starts when something happens in an app, at the times you schedule, or when you start it. Each start is one run.