Conditions, switches and delays

With the steps in the Logic group you decide which way a flow goes and when: the "if" and the "wait a moment". An example: if the invoice is still open after a week, create a task. They steer the actions that follow. Only Ask for a decision creates something itself, a task.

If / elseCopy link to this section

Splits the flow into two paths based on the data. It is the same principle as the filter under Only when of the trigger, but in the middle of the flow.

The step has two outputs: Yes (the conditions are met) and No (they are not).

1. Add an If / else step
2. Under Conditions, click Add condition
3. Pick the field with the Variable button, or type the path yourself, for example invoice.paymentStatus
4. Pick the comparison (is, is not, contains, is greater than, is less than, is one of, is empty or is not empty) and enter the value
5. Connect the Yes output and optionally No to a next step

An If / else step needs at least one condition. Otherwise Tillor says Add a condition. With several conditions you choose between All must match and Any may match. The comparisons work as described under Only when.

You do not have to connect both outputs. If an output leads nowhere, the run ends there. A flow that only does something on Yes is therefore fine.

You can also use fields from earlier steps. After an API request, for example, you can look at response.status or response.data.paymentStatus.

SwitchCopy link to this section

Choose Switch when you need more than two paths. The step looks at the value of one field and picks the branch that goes with it.

1. Under Field, pick the field you want to look at, for example occupation.occupationType
2. Under Branches, click Add branch. Enter the Branch (the name that appears on the output) and Equals (the value the field must have)
3. Repeat this for each branch
4. Connect each output to a next step

Each branch gets its own output below the step. There is also always a Default output. It is used when no branch fits.

• The field must match the value exactly, including capitals
• If more than one branch fits, the first in the list wins
• A branch without a value under Equals does not count
• You can set up to 8 branches, plus Default
• If the field is empty or does not exist, the flow goes via Default

Values of choice fields use Tillor's notation. An occupancy of the rental caravan type, for example, has the value RENTAL_CARAVAN, and a paid invoice has PAID.

DelayCopy link to this section

With Delay you make the flow wait before it carries on. You use it for things like look again a week later.

Under Wait, choose one of two ways.

For a fixed timeCopy link to this section

Choose For a fixed time and enter a number and a unit under Duration: seconds, minutes, hours, days or weeks. Seconds are not exact. The flow may carry on a few seconds later.

A delay of 0 does nothing, which is why Tillor says A delay of 0 does nothing.

Until a dateCopy link to this section

Choose Until a date when the wait depends on a date from the data, such as the due date of an invoice or the end date of a reservation.

Examples:

• Date invoice.dueDate, After, Offset 1 day: the flow carries on a day after the due date
• Date reservation.checkIn, Before, Offset 2 days: the flow carries on two days before arrival

If that moment is already in the past, or the date is empty, the flow carries on straight away.

What happens while it waitsCopy link to this section

• The run gets the status Waiting. On the Runs tab you can see when it carries on (Continues …). Long waits, such as weeks, are no problem
• After the delay Tillor reads the data again, so the steps after it see the current situation. See below
• If you pause the automation while it waits, the run stops as soon as the wait is over. It does not carry on and gets the status Canceled. If you switch the automation on before the wait is over, the run simply carries on
• If you delete the automation, the waiting runs stop
• If you change the flow while a run is waiting, that run finishes with the flow as it was when it started

Data is read againCopy link to this section

A run remembers the data from the moment of the event, but reads the records that belong to it again before it carries on. These are the record of the event (for example the invoice) and the records it refers to (for example the customer).

An example: an automation sends a reminder for an invoice, waits 7 days and then checks with If / else whether invoice.paymentStatus is not PAID. If the invoice was paid during that week, the condition sees the paid invoice and the flow goes via No.

There are two exceptions:

• If the record no longer exists, for example because an occupancy was deleted, the run keeps the copy from the moment of the event
• Data that an earlier step produced, such as the response of an API request, is not fetched again. If you want such data refreshed after a delay, make a new API request

Open now?Copy link to this section

Checks whether your organisation is open at this moment and splits the flow into Open and Closed. There is nothing to set up. Tillor uses the hours under Settings > Opening hours, with seasonal periods, public holidays and exceptions. See Organisation settings.

Use it, for example, to send a different text outside opening hours or to create a task. If you would rather wait until you are open again, use Wait until open. If you want to wait until you close, use Wait until closed.

Wait until openCopy link to this section

Pauses the flow until the next opening time and then carries on. Is your organisation already open? Then the flow carries on straight away. There is nothing to set up.

• The opening time comes from Settings > Opening hours, in your organisation's time zone
• If there is no opening time at all in the coming month, the flow carries on straight away instead of waiting forever
• While it waits, the run gets the status Waiting. What happens then is described under Delay

Wait until closedCopy link to this section

Pauses the flow until the next closing time and then carries on. Is your organisation already closed? Then the flow carries on straight away. There is nothing to set up.

• The closing time comes from Settings > Opening hours, in your organisation's time zone
• Blocks that join up, such as 9:00-12:00 and 12:00-17:00, count as one stretch. The flow waits until the end of that stretch
• While it waits, the run gets the status Waiting. What happens then is described under Delay

At most once per periodCopy link to this section

Only lets the flow through if it has not passed this step for the same record within the period. That way you do not send a customer the same reminder every day.

The step has two outputs: Continue if the flow has not passed through it within the period, and Already ran if it has. Connect Already ran to another step, or leave it empty so the run ends there.

Note the following:

• Only runs of the same automation count, and only if they passed this step via Continue
• The run that is going now does not count itself
• If the flow starts without a record, for example with Every day at a time, enter a variable yourself under Per. Without that value every run is new and the step stops nothing

An example: Period 7 days and Per {invoice.customerId} lets through at most one reminder per customer per week, even if that customer has several overdue invoices.

Look up a recordCopy link to this section

Loads a record based on its id, so the steps after it can use its fields. This is handy when the event only passes on an id, such as the message in an inbox conversation.

The step has two outputs: Found and Not found. If the record does not exist or the id is empty, the flow goes via Not found.

After Found, the fields of the record are in variables that start with found followed by the type: {foundCustomer.firstName}, {foundInvoice.displayId}, {foundReservation.checkIn}, {foundTerrain.name}, {foundInboxMessage.direction}. The other types are called foundOccupation, foundPayment, foundTask, foundAccessMethod, foundNfcTag, foundMeter and foundInboxThread. The records it refers to are included too, one level deep, such as {foundReservation.customer.firstName}. Everything is in the list behind the Variable button.

A second lookup of the same type replaces the first. Watch out with Task: it uses the same name foundTask as Find task, and the last of the two wins. The same goes for Document and foundDocument of Find document.

Map variablesCopy link to this section

Copies values to new variable names, so later steps can use one shape. This is handy when one flow starts via Incoming webhook ({body.…}) and via Invoice is overdue ({invoice.…}).

The step has one output: Next. If the source is exactly one variable between braces, for example {foundInvoice}, Tillor copies the whole record (object). Otherwise Tillor fills in the source as text, such as Invoice {foundInvoice.displayId} in meta.label.

A typical webhook test: Incoming webhook → Look up a record (Invoice, id {body.invoiceId}) → Map variables (invoice ← {foundInvoice}) → the same conditions and approval as with the schedule trigger.

Run codeCopy link to this section

Runs a piece of TypeScript on the variables of the flow and keeps what it returns as a new variable. For logic that you cannot fit into fields and conditions: which subtasks are needed, calculating an amount or date, reshaping a webhook body.

The step has one output: Next. This is how it works:

• The code only sees the variables it mentions. A variable the flow does not have is null; a date arrives as text (2026-07-01T10:00:00.000Z)
• Formatting and date shifts ({amount|currency}, {date + 1 day}) do not work here: calculate them in the code
• Return a list, text, number or object. You then read an object per field: {result.total}
• The code cannot fetch or send anything: no internet, no database. It only calculates. Calculating for too long (more than 50 ms) is cut off
• If the code throws an error, the run stops with that error and the line number. You see them on the Runs tab
• To the right of the code you immediately see what it returns on the sample; it runs along when you test

An example: after departure you want subtasks that depend on the terrain. Add a Run code step with:

const tasks = ["Plaats vegen", "Sanitair"];
if ({occupation.terrain.metadata.gasMeterNumber}) tasks.push("Gasmeterstand noteren");
return tasks;

Then fill the Subtasks field of Create task with only {result}: each text in the list becomes a subtask.

For eachCopy link to this section

Runs the steps after For each once for each item in a list, for example for each open invoice of a customer. The flow itself carries on via Done.

The step has two outputs with a meaning of their own:

• For each leads to the steps you want to take per item
• Done is how the flow itself carries on

This is how it works:

• Each item gets its own run, which goes through the steps after For each to the end of that branch. You see them on the Runs tab, which only shows the last 20
• The item is in the variable item, for example {item.id}. Variables of the event and of earlier steps stay available
• The flow does not wait until the items are finished. Immediately after they have started, it carries on via Done. So you cannot use the outcome of an item in the steps after Done
• At most 100 items are processed, the oldest first. If the list holds more, the rest are not processed
• If the list is empty or the Of field is empty, nothing starts and the flow carries on straight away via Done
• Open invoices of a customer are booked invoices with something still outstanding. Booked reservations of a customer are reservations with the status Booked

An example: an invoice becomes overdue and you want to make a payment link for each open invoice of that customer. Choose Open invoices of a customer, enter {invoice.customerId} under Of and put a Create payment link step after For each with {item.id} as the invoice.

Wait untilCopy link to this section

Checks conditions again and again until they are met, or stops after a while. Use it when you do not know when something will happen but do know what you are waiting for, for example until an invoice is paid.

The step has two outputs: Met (the conditions are met) and Timed out (the wait is over without them being met).

Note the following:

• The first check happens straight away. If the conditions are already met, the flow carries on immediately via Met. If you have not entered a condition, it is always met
• At each check Tillor reads the records of the event again, as with a delay. A condition such as invoice.paymentStatus is PAID therefore sees the payment as soon as it is there
• An interval under 5 minutes becomes 5 minutes
• While it waits, the run gets the status Waiting. Pausing and changing the flow work the same as with Delay

Wait for an eventCopy link to this section

Pauses the flow until something happens in Tillor, for example that the invoice has been paid.

The step has two outputs: Received (the event came) and Timed out (the wait is over without an event). If Only for the same record is on, a third output is added, Deleted. You use it when the record of the flow was deleted while the flow was waiting.

Note the following:

• With Only for the same record on, for example, only the payment of the invoice that started the flow counts. If you turn it off, every event of that type lets the flow carry on
• If you connect Deleted to nothing, Tillor stops the waiting flows of that record and deletes the tasks the flow created and only the flow could complete. If you do connect the output, the flow carries on there
• If the flow starts without a record, for example with Every day at a time, every event of that type counts
• An event that a step of an automation causes itself counts too. Waiting flows therefore also carry on because of work by Workflow
• After Received, the data of the event you were waiting for is in the variables, without the colleague who caused it. If you wait for invoice:paid, then {invoice.paymentStatus} gives the new state afterwards
• While it waits, the run gets the status Waiting. Pausing and changing the flow work the same as with Delay

Ask for a decisionCopy link to this section

Creates a task with buttons that you define yourself, and waits until someone chooses a button. That way you build in a moment where a person looks along, for example before the flow blocks a customer or books an invoice. Each option is a button on the task and an output of the step.

Setting up optionsCopy link to this section

1. Under Options, click Add option and enter the name, for example Approve. That name appears on the button and on the output
2. Click the coloured box to the left of the name (Icon and colour) to pick a colour and an icon. An icon is optional
3. Turn on Ask for a note if the colleague has to give a reason with this choice
4. Turn on Ask for confirmation if the colleague has to confirm first. You then enter a Confirmation title and Confirmation message and pick a Severity from Info, Warning or Destructive. You can use variables in these texts
5. Repeat this for each option. You can create up to 8 options

If the list is still empty, the Approve / Reject button immediately sets up two options: a green Approve and a red Reject. Each option needs a name, otherwise Tillor says Every option needs a name. Without options Tillor says Add at least one option.

OutputsCopy link to this section

The step has one output per option, with the name and colour of that option, plus always Timed out.

Note the following:

• The buttons are on the task card, in the task list and in the task itself. Such a task has no tick: you cannot simply complete it, only choose a button. After the choice the task is Completed and it shows which option was chosen. See Tasks with choice buttons
• Anyone assigned to the task can choose, also via a group, and so can administrators. If you assign nobody, anyone who can see the task can choose
• The task gets priority High. It is in the name of Workflow
• If the task is deleted before anyone chose, the flow carries on via Timed out. After Timed out because of the wait, the task stays
• Later steps can use {approvalTask.id}, {approval.decision}, {approval.label}, {approval.note} and {approval.decidedBy.name}. {approval.label} is the name of the chosen option and {approval.note} the note the colleague entered
• While it waits, the run gets the status Waiting. Pausing and changing the flow work the same as with Delay

What happens next?Copy link to this section

• An output you do not connect lets the run end there.
• With a wait step the run gets the status Waiting and carries on later. A paused automation stops waiting runs as soon as the wait is over.
• After a wait Tillor reads the data again, so the steps see the current situation.

Problems?Copy link to this section