Triggers
What starts a workflow: a button, a clock, or something happening elsewhere.
Every workflow starts with exactly one trigger, at the top of the builder. Steps below it can use the trigger's data.
Manually
Runs only when someone presses Run workflow. You can give the run an optional input, available to the steps as {{run.input}}.
Use this while you are building, and for jobs that genuinely need a person to decide it is time.
On a schedule
A fixed time, in a timezone you pick. Presets cover the usual shapes (hourly, daily, weekdays, weekly, monthly), and there is a custom option using cron for anything else.
Set the timezone deliberately. A daily 9:00 run means 9:00 wherever you set it, not wherever the reader is. A digest for a team spread across three countries wants the timezone of the people who act on it.
You can give scheduled runs a fixed input, and switch the schedule off without deleting the workflow.
When something happens
Rather than waiting for a clock, a workflow can run when something changes: an email arrives, a calendar event moves, a file lands in a Drive folder, a document appears in one of your collections.
The exact list is growing, so check the When should this workflow run? picker in the builder for what is available to you today. What follows is how they all behave, which is the part worth learning once.
The trigger hands its data to your steps
Whatever fired the trigger is available to every step below it, as {{trigger.something}}. A calendar trigger passes the event's title and start time, a Drive trigger passes the file's name and link, and so on.
Type / in any step field to see what this particular trigger offers and insert it, rather than guessing at the name.
Some triggers pass a pointer, not the contents
Worth knowing because it changes how you build the first step.
The Gmail trigger is the clearest example: it passes only the message ids, not the subject or body, because Asteria Cloud does not keep a copy of your mail. A step that needs to read the message does so through the Gmail tool, at that moment.
The practical consequence: a step reacting to email needs the Gmail tool attached. The trigger alone will not have handed it the content. If a step comes back empty, this is the first thing to check.
Watching a folder or a collection
Two things catch people out.
Drive triggers watch direct contents only. A file added to a sub-folder of the one you named does not fire it. Point it at the folder where things actually land.
A collection is usually shared, so a trigger on one fires on what colleagues and agents put there, not only on your own uploads. That is normally the point, since it is how you process a shared pile of incoming documents. It does mean a busy collection can start a lot of runs.
When a trigger will not turn on
Event triggers need a working connection, and the builder says which piece is missing rather than failing quietly. The messages fall into three groups:
You can fix it. Anything telling you to connect or reconnect your account: go to Profile then Connections. A trigger that was working and now says it is disconnected is almost always an expired or withdrawn permission.
An administrator has to fix it. Anything mentioning your organisation's own application or its setup. These are not things you can grant yourself, so send your administrator the message you are seeing.
It failed to subscribe. Switch the trigger off and on again, and if it persists ask your administrator.
Every event trigger shows when it was last checked. That is the quickest way to tell a live trigger from one that has quietly stopped listening, and it is worth glancing at when a workflow "has not run for a while".