Automations

An automation does something for you when something happens to a record: it sets fields, moves it to another state, leaves it a comment or sends its data to another system. They're set up in Edit application → Automations, and only whoever can edit the application's pages sees them.

How one is built

• Entity — the automation acts on the records of one entity.
• When — what sets it off: a record is created, updated, changes state (to any state or to one in particular) or is commented on. A state change needs an entity with states, and a comment, one that takes comments. It can also be a time (see below): on a schedule, when a date comes or when a record stays in a state.
• Only if — an optional condition, written as a formula that holds or not: [total] > 1000 AND [priority] = 'High'. It reads the record's fields, those of the records its relations point at and of those pointing at it. If it reads an empty field, it doesn't hold. ME() is whoever set it off: [assignee] = ME().
• Actions — they run in order, each on the record as the one before left it:
  • Set fields — each value is written as a formula, such as TODAY() or [quantity] * [price]. If it reads an empty field, the field is left empty. Text, number, date, checkbox, email, phone and choice fields can be set; formulas and folios work themselves out.
  • Change state — moves the record to another state of its entity.
  • Comment — the text is written as a formula too, such as 'Done: ' & [folio]. If it reads an empty field, nothing is commented.
  • Create a record — creates a record of any entity of the application, in its first state and numbered by its folios. It creates one, or one per entry of one of the record's dialogs.
  • Notify — tells people about the record, in the bell and, if chosen, by email: whoever created it, whoever made the change, users and groups of the application, whoever its user fields hold, and the addresses in its email fields. Its subject and message are written as formulas too. See notifications.
  • Send to a web API — sends the record's data to another system. See Send to another system below.

Each value of a created record is written as a formula that reads the record that set the automation off. Per entry, [lines].[quantity] reads that entry's quantity, not the list of all of them. A relation is picked from a list: it can point at the record that set it off, at what a relation of that record points at, or at what a relation of the entry points at. A relation holding many records can also take all those another holding many points at. If one entry can't be saved, none is created.

This is how stock goes down: when a sale is created, an automation creates a movement per line, pointing at the line's product and at the sale, with the quantity negated; the product's stock sums its movements with SUM([Movements ← product].[quantity]).

An automation that's off is kept but doesn't run.

While an automation uses a state, a field or comments, they can't be taken away: removing the state, the field from its form, or turning comments off is refused, saying which automation needs them.

Send to another system

When another system needs to hear about something, such as an approved order or a solved ticket, an automation sends it the record's data. The system has to be connected as a web API by an admin; the automation uses its headers, so you never see its keys.

• Web API — which one to send to, of those connected.
• Method — POST to create something in the other system, PUT to replace it or PATCH to change just a part. If you're not sure which, ask whoever runs that system; POST is the most common.
• Path — what goes after the API's address. {folio} puts that field of the record there: orders/{folio}. Left empty, it's sent to the address as is.
• Data sent — each with a name and a value written as a formula. Numbers, dates and checkboxes are sent as such, and an empty field is sent empty:

{ "folio": "ORD-0012", "total": 1500, "delivery": "2026-10-21" }

Sending doesn't hold up the change that set it off: it goes out in the background, a few seconds later. If the other system doesn't answer or turns it down, it's tried again a few times, each a little later. In the runs, the automation counts as run as soon as the sending is queued.

Set off by time

Three triggers don't wait for someone to change a record:

• On a schedule — every day, every week on the chosen days or every month on a day, at a time. Each time it runs on every record of the entity whose condition holds. On a day 31, a shorter month takes its last day.
• A date comes — a while before or after the date in a date or date and time field: 1 day before the due date, 2 hours after the appointment. A date alone counts from midnight. If the record's date changes, it counts from the new one. Only dates still to come when the automation was saved count.
• A record stays in a state — once a record has been in a state, or in any, for a while: 3 days in Pending. If it leaves the state, the count starts over when it comes back.

Times are read in the application's time zone, set in Edit application → Time zone. A new application takes the zone of whoever creates it. Changing it moves the schedules to the new zone. The application's pages also show their times in it, such as a record's history and comments; elsewhere, times are in your browser's zone.

The list of automations shows when a scheduled one runs next. Time is checked every half minute or so, so it may run a little after its time. If Selfform was stopped when it was due, it runs once when it's back, not once for every time it missed.

What it does is done on behalf of Selfform, as the record's history shows. Its runs list only those where it ran or failed: one whose condition wasn't met isn't kept.

On whose behalf

What an automation does is done on behalf of whoever set it off: if Diego saves a sale and an automation marks it paid, the change is Diego's. But the record's history and comments also say what made it: Updated by Diego · via the automation “Mark paid”.

The automation acts on its own authority: it was set up by someone who edits the application, so it doesn't depend on the permissions of whoever sets it off. It can, for instance, fill in a field that user can't edit.

Runs

Runs shows the latest 50 times it was set off, the most recent first: when, who set it off and whether it ran, its condition wasn't met or it failed, and why. An automation failing never undoes nor stops the change that set it off.

What an automation does can set off others too. Each runs on a record once in all a change sets off, and the chain stops five levels deep.