A trigger decides when an automation runs by itself: when something happens in Pyron, when another system calls in, or at a set time. You can also run a switched-on automation by hand whenever you need to, and preview any automation before it goes live.
Event triggers
An event trigger runs the automation each time a chosen action completes in Pyron, such as an entry being created or updated, an email being sent, a report being generated, or another automation finishing, succeeding or failing. The events on offer are the actions people and automations take, not the internal steps inside a run.
Adding a trigger
Every automation's page lists what starts it under When, however the automation was made — from a project, from New automation, or by the assistant in the chat. One that nothing starts yet says "Nothing starts it yet."
- On the automation's page, select Add trigger beside When.
- Choose what starts it:
- Schedule: how often (every day, weekdays, weekly or monthly), which day, what time, and the time zone it keeps.
- Incoming call: the address another system posts to, with Copy address. Each call presents an API key whose service account may start automations.
- Event: someone doing something in Pyron, such as "Someone creates an entry".
- Select Add.
A new trigger starts runs once the automation is switched on. On an automation that is already on, On (checked) switches the new trigger on as it is added. The page then says when a schedule first runs.
To change a trigger, open the ⋯ menu on its row: Change sets a schedule's timing and whether any trigger is on, and Remove takes it off the automation after you confirm it by name. A trigger Support set up for you is yours to change or remove like any other. You can also ask the assistant to add a trigger while it builds an automation: it adds it the same way, switched off.
Choosing the event and a condition
Pick the event from the list. A short description of the event appears beneath it once chosen.
To run the automation for only some of those events, add a condition. A condition is a set of rules, each comparing one field of the event's details with a value: equal or not equal, contains, greater or less than, is one of, is not one of, is empty, or is not empty. You choose whether all of the rules or any of them must hold, and you can nest groups of rules for finer control. With no rules, every occurrence of the event runs the automation.
When a file is added
Choose Someone adds a file to run the automation when a file is ready in Files: once it has been checked for viruses, never while it is still being checked. Moving a file into another folder or place counts as adding it there, so an automation watching a folder also sees files people file into it. Narrow it with:
- Place: a place and every place under it.
- Folder: the folder's name, such as Guard tours.
- Kind: documents, photos, spreadsheets and so on.
- Added by: a person, a guest, a visitor, an automation, the API or the assistant.
The trigger then reads as you set it: "When a spreadsheet is added to “Guard tours” in Site 4". The automation can read the file's text or a spreadsheet's rows, and save a spreadsheet or a report's PDF back to a folder.
Filling the automation's inputs
The inputs an automation declares in the editor get their values from the trigger. For each input, choose the piece of the trigger's details that fills it: a field from the event, the moment a schedule fired, or part of an incoming request's body.
Pyron checks each choice against the input's type. A value that does not fit is flagged, and options that cannot fit are greyed out. Every required input must be filled before the automation can be switched on.
The trigger reads the automation's saved inputs. If you have just added an input in the editor, save the automation before you map a trigger to it.
When an event-triggered run starts
An event-triggered run starts in the background just after the action is saved. If the action fails and nothing is saved, the trigger does not fire.
Event-triggered runs act as the automation's service account, not as the person whose action set them off. An automation with an event trigger cannot be switched on without one when its steps need permissions to run. The automation's run history still shows who caused each run.
Automations can set each other off: one automation's steps cause an event that triggers a second, which triggers a third. Pyron limits how deep such a chain can go, so an automation that ends up triggering itself stops rather than looping forever.
Incoming web requests
A web request trigger gives the automation an address that another system can call. You set the path, using letters, numbers, /, - and _, up to 255 characters, for example /hooks/new-delivery. The full address sits under /api/webhooks/ on your organisation's Pyron address, and only one switched-on automation can hold a given path at a time.
Next, choose how the call is answered:
- Answer straight away. The caller gets an acknowledgement and a run reference straight away, and the automation carries on in the background.
- Wait for the automation to reply. The caller waits while the automation runs, and a reply step inside the automation composes the answer. You set how many seconds the caller waits at most; a run that takes longer, fails, or finishes without replying sends the caller an error.
An automation that waits must contain exactly one reply step, and one that responds immediately must contain none.
Every call must prove who it comes from, either with an inbound API key whose service account is allowed to run automations, or with a signed request. Pyron checks the request body against the inputs it fills and turns away a call whose values do not fit. For the request format and signing scheme, see the API and webhooks reference.
Schedules
A schedule trigger runs the automation at set times. There are three ways to describe the schedule:
- A preset: every 15 minutes, every 30 minutes, or every hour.
- A simple schedule: daily, weekly or monthly, at an hour and minute you choose. A weekly schedule also takes a day of the week, and a monthly one a day of the month.
- An advanced schedule: five fields for minute, hour, day of the month, month and weekday. Each takes a number,
*for every value, or*/nfor every nth value. For example, minute0, hour7, day*, month*and weekday1-5runs at 7:00 every weekday.
Each schedule has its own timezone, which starts on your browser's timezone. Beneath the fields, a summary spells out the schedule in words, so check it reads the way you mean before you save.
The moment a schedule fires is one of the values you can pass into the automation's inputs, which helps an automation that reports on the day or the week it ran for.
Pausing an automation keeps its schedule. The trigger stays in the Setup list, shown as off, and resumes when you switch the automation back on. Switching it on does not set off an extra run: the first run is the next scheduled time.
To email a report on a regular cycle, use a report schedule rather than building the automation yourself.
Manual runs
Running an automation by hand
When an automation is switched on, its editor offers a button that runs it straight away. If the automation has no inputs, it starts at once. Otherwise a form opens for you to fill in the input values first, prefilled with any sample or default values the inputs carry.
A manual run is a real run: emails are sent and entries are written. It acts as the automation's service account, and records you as the person who started it. The outcome appears in run history, and a run that fails is kept there with its error, so you can see what went wrong. Running an automation by hand needs a role that allows it.
Automations that run on request
Some automations are made to be started by people whenever they need them, such as "Summarise a site's week for its manager". Such an automation runs on request: its page says in one line when it is useful, and the Automations list can show only these with the Runs on request filter. The assistant writes the line when it builds the automation.
Select Run now on its page, fill in what it asks for, and select Run. A run you start this way acts as you, with your permissions, never as the automation's service account, so it can only do what you could do yourself. When another automation starts it, it acts as that automation. An automation that runs on request can be started only while it and its on-request trigger are both switched on.
Previewing with a dry run
A dry run previews the automation without doing anything real. Steps that would change something, such as sending an email or writing an entry, are replaced with stand-ins, so you can follow how values move from step to step. A dry run works on a draft as well as a switched-on automation, which makes it the safe way to test a change before you switch it on.
Like a manual run, a dry run asks for input values when the automation has inputs. Any unsaved changes in the editor are saved first, so the preview runs the version you can see.
From a lifecycle action
A trigger can tie an automation to a lifecycle action, so it runs whenever someone takes that action on an entry. Choose the action from the list, where each action is shown under its lifecycle.
This trigger hands the automation fixed values: the entry, its lifecycle, the action taken, and anything the person filled in on the action's form. Pyron adds a matching input for each of these when you save the trigger, so there is nothing to map.
Unlike the other triggers, a lifecycle action runs the automation as the person who takes the action, with their permissions. Each action can drive only one switched-on automation. For how people take actions on entries, see working a lifecycle.