Automations

What is an automation

An automation is a rule of the form "when X happens to a record of this entity, do Y," which fires automatically on the server, without human involvement. Compared to business processes, this is the simplest mechanism: an automation doesn't show the user any tasks and doesn't wait for any action from them — it just executes the configured logic at the moment of the event.

Automations are configured in the entity editor, on the Automation tab (available once the entity has been saved at least once). The list of rules is shown as expandable blocks; the Add Rule button adds a new rule, and in the empty state there's a Create your first rule link.

Each rule consists of:

• a name (the "Rule Name" field),
• a trigger — the event the rule fires on,
• an optional condition,
• one or more actions, executed when the rule fires.

Triggers

The full set of record lifecycle events is available, plus a separate type for running on a schedule:

Trigger	When it fires
Before Create	Before a record is created — useful for validation and setting default values
After Create	After a record is created — useful for notifications and logging
Before Update	Before record changes are saved — useful for computations and validation
After Update	After changes are saved — useful for syncing with other data and auditing
Before Delete	Before a record is deleted — useful for checking whether deletion is allowed
After Delete	After a record is deleted — useful for cleaning up related data
Scheduled (Cron)	On a schedule, not tied to an event on a specific record — see Scheduled Automations below

On "Before" triggers, you can modify the record's data before it's saved (the action script has access to an array of the record's data being saved/changed). On the Before Create and Before Delete triggers, you can abort the operation by throwing an exception in the action script, which cancels the create/delete operation with an error message.

Condition

For the Before Update and After Update triggers, a Only run if the field changed checkbox is available. When enabled, you choose a specific field from the entity's field list — the rule will only fire if that field's value actually changed when saving. For other triggers, the condition isn't shown (it doesn't apply — for example, on creation there's no "old" value to compare against yet).

There are no other types of conditions (multiple conditions, comparison operators, AND/OR) at the rule level — more complex filtering (for example, "the field changed and the new value equals X") is implemented inside the action script, based on the data passed to it.

Actions

A single rule can have multiple actions, executed in sequence. Three types are available:

Script Block (PHP) — run a script

An arbitrary PHP script that runs in a sandboxed environment (dangerous operations are blocked — running shell commands, direct filesystem access, direct DB/Artisan access, etc.). Inside the script you have access to:

• $data — the record's data. Changing this array on before triggers is saved together with the record.
• $user — the current user (id, name, email), or null if the action was triggered by the system (for example, on a schedule).
• $oldData — the record's data before the change (available only on update triggers).
• $api — a helper object with methods for working with data:
  • $api->get('table', $id), $api->find('table', 'field', 'value'), $api->query('table', $conditions, $limit) — reading records (including conditional queries — the only way to find the records you need in scheduled scripts);
  • $api->updateRecord('table', $id, $data) — updating another record;
  • $api->getRelatedByTable(...), $api->addRelatedByTable(...), $api->unlinkRelatedByTable(...) — working with related records;
  • $api->sendTelegram(...), $api->sendEmail(...), $api->sendPushNotification(...) — sending notifications;
  • $api->now(), $api->parseDate(...), $api->log(...) — utility helpers;
  • $api->categoryPath(...), $api->categoryAncestors(...), $api->categoryIsDescendantOf(...), $api->categoryChildren(...), $api->categoryFindByName(...), $api->categoryFindByPath(...) — working with tree-structured category catalogs.

To stop a record from being saved, the script must throw an exception (throw new \Exception("error text")).

Set Category (no-code) — set a category without code

A no-code action: automatically sets a value in a Category-type field (see Field Types). You configure:

• Target field — which category field to populate;
• Mode — Static Value (always the same catalog node) or From Another Field (look up a node based on a text field's value on the record);
• when looking up from a field — search By Node Name or By Full Path (with a configurable separator, for example "Electronics/Phones"), with the option to limit the search to a specific parent branch;
• If Node Not Found — leave the field as is, clear the field, or abort the save with an error.

If another business process also writes to the same field, the builder shows a warning about a potential execution-order conflict.

Start Process (BPMN) — launch a business process

Launches the selected business process template, passing the current record as input. It requires an existing record, so on the Before Create trigger this action does nothing (the record doesn't have an id yet).

The Set Category and Start Process actions aren't available for the Scheduled (Cron) trigger — only Script Block (PHP) can be used with it.

Scheduled automations

Automations with the Scheduled (Cron) trigger are the platform's most recently added mechanism. Unlike other triggers, they aren't tied to an event on a single record — they run on a schedule globally for the whole entity. This is useful for regular batch operations: checking overdue deadlines, calculating SLAs, periodic cleanup, syncing with external systems.

How to configure it

1. Open the entity's Automation tab, create a rule (Add Rule) or open an existing one.
2. In the Trigger Event field, select Scheduled (Cron).
3. Fill in the Cron Expression — a standard 5-field cron expression (minute, hour, day of month, month, day of week). Preset buttons are available nearby for quick entry: Every 5 Minutes (*/5 * * * *), Every 15 Minutes (*/15 * * * *), Hourly (0 * * * *), Daily at 09:00 (0 9 * * *).
4. The Active checkbox lets you temporarily pause the rule without deleting it (interface label: "uncheck to pause without deleting").
5. Add a Script Block (PHP) action — the only supported action type for schedules. Since the schedule isn't tied to a specific record, the script doesn't have a ready-made $data/$oldData — you need to find the relevant records yourself via $api->query('table', $conditions, $limit), for example selecting all overdue tickets and updating them via $api->updateRecord(...).
6. Next to the schedule settings is a ▶ Run Now button — it runs the rule immediately, without waiting for the schedule, and shows the result right away ("Completed successfully" or the error text).

How it works technically

Schedules require no separate server-side setup — the Laravel scheduler runs a system command every minute that checks the cron expressions of all enabled scheduled rules across all entities and determines which ones are "due" (by comparing the cron expression against the time the rule last actually ran). Any rules that are due run automatically.

Where to check status and run history

All scheduled rules across all entities are collected on a single Cron Jobs screen (Application Management → System → Cron Jobs, address /cron-jobs). The table shows:

Column	Contents
Entity	Which entity the rule belongs to
Rule	The automation's name
Schedule	The cron expression
Active	Active / Paused
Last Run	Date and time of the last actual run
Status	Success / Error (on error — the error text in a tooltip) / Never run yet
Next Run	Estimated time of the next run, based on the cron expression
Actions	Run Now and Open Entity buttons (jumps to the entity editor, to this rule)

Important: only the last execution result is stored for each rule (time, status, error text on failure) — not a full history of every past run. The screen shows the current state of the schedules, not a log. If a rule runs multiple times, older results aren't kept — each new run overwrites the previous result for that rule.

How automations differ from business processes

Automations and business processes solve different problems, and in the entity editor they're two separate mechanisms (the Automation and Processes tabs):

• Automation is server-side logic with no human involvement: "if X happens, do Y" or "do Y on a schedule." There are no tasks and nothing waits on anyone's decision. Good for validation, computations, setting values, notifications, and periodic operations.
• Business process is a BPMN diagram with explicit tasks for people: an approval request, waiting for work to be completed, branching based on a user's decision. Good for cases where a step in processing the record requires a deliberate human decision.

Both systems can modify the same record fields (for example, both an automation and a process can change the status or fill in a category field) — that's exactly why the editor shows a warning about a potential conflict if both mechanisms write to the same field. In practice, many entities use both: automations for routine checks and calculations, and a business process for the steps that need human action.