Published Flows
Every flow that has been published from the Designer, and the place you schedule them.
A flow appears here once a version of it is published — see Versions. Until then it exists only in the Designer and cannot be scheduled, triggered, or run through the API.
Each row carries the flow name, when it was last modified, its id, and how many versions have been published.
Actions
The menu at the end of a row:
Scheduling
Schedule opens the dialog that turns a published flow into a recurring job:
| Field | Notes |
|---|---|
| Flow and Version | Which published version to run. Pinning a version is the point — it keeps running while you edit master |
| Name | What the schedule is called in lists and the calendar |
| Robots | Which robots may run it. More than one gives you failover |
| Priority | Which job wins when robots are contended |
| Timezone | Interpreted for the schedule, not the robot's local time |
| Schedule Period | Minutes, hours, days, weeks or months, and the interval within it |
| Allow To Run In Cloud | Falls back to a cloud robot when none of yours is connected |
The Schedule Summary panel restates your choices as a sentence as you fill the form — worth reading before saving, because a wrong timezone or interval is easier to catch in prose than in fields.
The timezone here is the one the schedule is interpreted in. A robot in another timezone still runs at the moment this schedule specifies — which is usually what you want for a business process, and surprising if you assumed otherwise.
Editing
Edit renames the published flow and manages its labels:
Renaming here changes the published flow, not the flow in the Designer.
Labels are key-value pairs. They are how you group flows across projects — by team, by environment, by customer — and they are worth setting early, because retrofitting labels to fifty flows is nobody's afternoon.