Triggers
Choose when an automation starts, including on a date such as the arrival, filter the cases and limit it to once per record
Last updated on
The trigger is the starting moment of an automation: the "when". It sits at the top of every flow, under the name When this happens. An example: start when an occupation ends. It also determines which data the steps after it can use. A flow can have several triggers. Each trigger starts a run of its own, with its own filter. You add one from the list on the left. You cannot delete the last trigger.
What the automation starts on
Under Starts from you choose one of seven starting moments.
| Choice | Starts when |
|---|---|
| When something happens | An event takes place in Tillor, such as an occupation that ends or an invoice that is paid |
| Invoice is overdue | A booked invoice is still open after its due date |
| Incoming webhook | Another system sends a message to the automation's own address |
| A task action is chosen | Someone picks a choice button on a task that is linked to this automation |
| A date is reached | A date of a record is reached, optionally some time before or after it. For example one day before the arrival of a reservation |
| Every day at a time | It is the chosen time every day |
| On a cron expression | It is the turn of the schedule you give |
So you first choose the kind of starting moment, and then the details. If you choose a different starting moment, the filters under Only when are cleared. They were written for the previous choice and no longer fit.
When something happens
Under Event you choose what the automation should start on. Click the field and type to search, for example occupation or invoice. The events are written in Tillor's notation, such as occupation:ended: first what it is about, then what happened.
These are the events you need most often:
| Event | Starts when |
|---|---|
occupation:ended | An occupation ends |
reservation:created | A reservation is created |
reservation:updated | A reservation is changed |
customer:created | A customer is created |
customer:updated | A customer is changed |
invoice:created | An invoice is created |
invoice:updated | An invoice is changed |
invoice:paid | An invoice has been paid |
payment:created | A payment comes in |
task:created | A task is created |
task:status-changed | The status of a task changes |
task:assigned | A task is assigned to someone |
task:action-chosen | Someone picks a choice button on a task |
integration-alarm:created | A meter raises an alarm |
comment:created | A comment is posted |
document:created | A document is added |
signatureRequest:updated | A signature request is updated |
signatureRequest:completed | All signers of a signature request have signed |
mandate-agreement:signed | A customer has signed a SEPA mandate |
mandate-agreement:activated | A SEPA mandate has become active |
mandate-agreement:expired | A request for a SEPA mandate has expired without a signature |
mandate-agreement:failed | The activation of a SEPA mandate was refused or failed |
productPriceChange:applied | A scheduled product price takes effect |
This is the same list as that of the webhooks. So you can use every event for which Tillor can send a webhook. A few events that occur extremely often, such as the physical state of barriers, typing in the inbox, controller logs and vehicle presence, are not in the list.
Missing an event?
Under the Event field is the link Missing an event? Request it. See Requesting a step or event.
Which data you get
Most events come with a record, such as an occupation, an invoice or a task. That record, plus the records it refers to, are then available as variables in the steps. With occupation:ended you can use, for example:
{occupation.terrain.name}for the name of the terrain{occupation.customer.firstName}for the customer's first name{occupation.reservation.displayId}for the number of the reservation. Not every occupation has a reservation: in that case this stays empty
There are also always {triggeredBy.name} and {triggeredBy.id}: the colleague who caused the event. If the event was caused by the system, for example by a bank synchronisation, those fields are empty.
Under the trigger's settings is Data this event provides. There you see exactly which variables you can use. For an event whose data is not described, Tillor says there is nothing to choose. Variables that you type yourself still work then. See Variables and templates.
A task action is chosen
Some tasks have choice buttons instead of a tick box, for example from Ask for a decision. A button can be linked to an automation. With this trigger, that automation starts as soon as someone picks that button. See also Tasks with choice buttons.
Linking a button to an automation is not done in the flow editor. If you need this, ask your Tillor administrator or support.
The steps receive the data of the task, for example {task.name} and {task.id}, plus {action.label} (the name of the chosen button) and {note} (the note the colleague filled in, if the button asked for one). Under Data this event provides you see the full list.
Invoice is overdue
This trigger starts for every invoice that:
- is booked (drafts and cancelled invoices do not count)
- is not a credit note
- still has an outstanding amount
- has a due date before today
A run of its own starts for each such invoice. The data of the invoice and the customer is available as {invoice.…}, for example {invoice.displayId}, {invoice.amountOutstanding} and {invoice.customer.firstName}.
If you turn Run once per record off, the automation starts for the same invoice at most once a day for as long as it is overdue. If you leave it on, it starts exactly once for each invoice. That is usually what you want for a reminder.
Under Due for a reminder you choose how long the invoice must already have been open, the same rule as in the invoice list. Turn on Exclude customers who do not receive automatic reminders to skip customers who have that set in their invoicing settings. An invoice that has itself been taken out of the automatic reminders does not start the flow either.
Incoming webhook
A webhook is a message that another system sends to an address. With this trigger, that system starts the automation, for example your website, a form or a booking platform. Every automation gets a secret address of its own.
- Under Starts from choose Incoming webhook
- Save the automation. The URL appears under Address
- Click Copy and set the address in the other system
- Turn the automation on
The other system sends a POST with JSON to that address. The content is then available as {body.…}, for example {body.email} or {body.reservering.nummer}, and parameters in the URL as {query.…}. With Only when you can filter on those fields too.
This is how it works otherwise:
- The address is the secret. Anyone who knows it can start the automation. So share it only with the system that needs it
- If the address leaks, click New address and save. The old address stops working from then on
- A disabled automation or a wrong address gives a
404error - The content may be at most 100 KB
- Each call starts one run per webhook trigger in the flow. The address belongs to the first webhook trigger. New address on that trigger replaces it
- No record is linked to it, so Run once per record has no effect
Ignoring repeats
If the other system sometimes sends the same call twice, Ignore repeats prevents the flow from starting twice. Tillor remembers a key of the call. If the same key comes in again, nothing starts.
| Choice | What the key is |
|---|---|
| Every call starts the flow | There is no key. The default |
| From a header | The value of a header that you choose under Header name, for example Idempotency-Key |
| From the JSON body | The value of a field in the JSON, which you choose under Field, such as id or data.eventId |
| Same JSON body | The whole content. A call with exactly the same content counts as a repeat |
Under Remember the key for you choose how long the key applies, in hours, days or weeks. After that time the same key starts the flow again. At 0 the key applies until you delete the automation. A call without the chosen header or without the chosen field is rejected.
A date is reached
This trigger starts on a date of a record. Under Date you choose any date field of a record that Tillor also sends along with events, written as record and field. A few examples:
| Date | Record |
|---|---|
reservation.checkIn | The arrival date of a reservation |
reservation.checkOut | The departure date of a reservation |
invoice.dueDate | The due date of an invoice |
task.dueDate | The deadline of a task |
occupation.paidUntil | Until when an occupation is paid |
accessMethod.periodTo | The end of the validity of a QR code, number plate or other access method |
nfcTag.activatedUntil | Until when an NFC tag is activated |
mandateAgreement.expiresAt | When a request to sign a SEPA mandate expires |
customer.birthday | A customer's date of birth |
contact.birthday | A contact person's date of birth |
By default the trigger starts once, on the date itself. Turn on Repeat every year to count only the day and month: the flow then starts again every year, such as on the birthday with contact.birthday. A 29 February falls on 28 February in other years.
You can also choose data that is stored with a record as extra fields. document.userMetadata.insuranceExpiryDate is the expiry date of a document, such as an insurance payment proof. A date without a time like that counts as midnight (UTC, the international standard time). With Only when you then limit the trigger to one type, for example document.userMetadata.documentType is INSURANCE_PAYMENT_PROOF, and to active documents with document.status is ACTIVE.
With How long and Before or after you shift the moment. 1 day and Before on reservation.checkIn starts the flow a day before the arrival. At 0 it starts on the date itself. A date without a time counts as midnight.
With Time you choose when on that day the flow starts. The time in the date uses the moment that is in the field, such as the arrival time of a reservation. Fixed time of day starts on the day of the date at the hour and minute you choose, in your organisation's time zone. That is how contact.birthday with Repeat every year starts every year at 09:00 on the birthday. How long then counts from that time: 1 day and Before starts the day before at 09:00, even if the clocks change that night.
A run of its own starts for each record, with the data of that record as variables, for example {reservation.displayId} and {reservation.customer.firstName}. With Only when you limit it, for example to reservations with the status booked only.
This is how it works otherwise:
- The flow starts once per record and per moment. If the date moves to later, for example because a guest arrives later, it starts again at the new moment
- If the moment had already passed when you saved or enabled the automation, it no longer starts for it
- Missed moments, for example during maintenance, are still caught up by Tillor for up to an hour afterwards
Every day at a time
Under Hour choose an hour (0 to 23) and under Minute a minute from 0 to 59. The time is the time in your organisation's time zone.
The steps receive {now}: the moment the run started.
On a cron expression
Choose a rhythm, such as every day, every Monday at 08:00, or the odd Mondays (the 1st, 3rd and 5th). Under Custom you set the interval, the weekdays and the time, down to the minute. Under Cron expression you write the schedule yourself.
A cron expression is a short way of writing a repeating time. It has five parts, separated by a space: minute, hour, day of the month, month and weekday.
| Expression | Meaning |
|---|---|
0 8 * * 1 | Every Monday at 08:00 |
7 8 * * 1 | Every Monday at 08:07 |
30 7 * * 1-5 | Every working day at 07:30 |
0 9 1 * * | On the first of every month at 09:00 |
0 8 * * 1#1,1#3,1#5 | Every odd Monday (1st, 3rd and 5th of the month) at 08:00 |
0 8 * * 1L | The last Monday of the month at 08:00 |
0 8 * * 1 W2:2026-10-05 | Every two weeks on Monday at 08:00, starting from the week of 5 October 2026 |
*/15 * * * * | Every quarter of an hour |
* * * * * | Every minute |
In each part you can use a number, a list with commas (8,17), a range (1-5), a step (*/15) or an asterisk (*, every value). Weekday 0 and 7 are both Sunday. 1#2 is the second Monday, 1L the last. A sixth field W2:2026-10-05 repeats every two weeks, counted from that week. Names such as MON or JAN do not work. If you fill in both a day of the month and a weekday, the automation starts on either of the two.
If the expression is invalid, Tillor reports that at the trigger. The times apply in your organisation's time zone.
Exactly when does a schedule start
A schedule starts in the minute in which it is due
Tillor checks every minute which schedules are due. An automation that should start at 08:07 starts in that minute. This applies to Invoice is overdue, A date is reached, Every day at a time and On a cron expression.
A schedule starts at most once per minute. A check that only runs in the next minute does not catch up on the previous minute.
Events start immediately, without this delay.
Only when
With Only when you let the automation start only if the data matches. That way you start, for example, only for static caravans, or only for invoices above a certain amount. Leave it empty to start for every event of this type.
- Click Add condition
- Choose the field with the Variable button (or type the path, for example
invoice.status) - Choose how you compare
- Fill in the value. For fields with a fixed choice, such as a status, a terrain type or a colleague, you choose from a list
You can use the following comparisons:
| Choice | Matches when |
|---|---|
| is | The field equals the value |
| is not | The field does not equal the value |
| contains | The value occurs somewhere in the field |
| is greater than | The field is greater than the value (for numbers and dates) |
| is less than | The field is less than the value (for numbers and dates) |
| is one of | The field equals one of the chosen values |
| is empty | The field is empty |
| is not empty | The field is not empty |
Capitals do not matter. Numbers are compared as numbers, so 10 is greater than 9.
If you have more than one condition, you choose how they work together: All must match or Any may match.
Events that are held back by the filter do not start a run and so leave no trace on the Runs tab. If you want to see whether your filter is right, use Test run: there you see for each condition whether it matched.
Run once per record
With Run once per record the automation starts at most once per invoice, reservation or other record, however often the event occurs for it.
That is especially handy for events that come back often, such as invoice:updated: an invoice is changed dozens of times, but you only want to send one reminder. Tillor remembers per record that the automation has already started. That memory disappears when you delete the automation.
It only works for events that come with a record, and for Invoice is overdue and A date is reached. With A date is reached it means: even if the date moves later, the flow does not start again. For a schedule such as Every day at a time it has no effect.
What happens next?
- Every time the starting moment occurs and the filter matches, a run starts with the data of that moment as variables.
- An event starts immediately. A date, hour or schedule starts in the minute in which it is due.
- If the filter does not match, nothing starts and there is no trace on the Runs tab.