Events — what starts a rule

A rule has exactly one event. If you need two, create two rules.

Step by step

Select an event in the rule wizard

1. Open Tools → Automation from the side menu. The Rules tab opens, beside Custom events.
2. Click New rule, the plus button on the right of the bar above the list.
3. In the dialog’s left column under Trigger, open Select event.... The list is grouped by area: Orders, Products, Documents, Returns, Consolidated parcels (ZRS) and Warehouse. In each group, system events come first and your company’s custom events last; custom events have a hand icon.
4. Select one event. A badge for its area, for example Orders, appears in the dialog header beside the rule name. This field is derived from the event and cannot be set manually.
5. Click the information icon beside the event field to read its description.
6. Only after selecting an event can the right column accept actions. Until then it says Select a trigger first to add actions.
7. Add at least one action with Add action, then click Save. Saving a rule has an extra verification step. If the sensitive-operation session has expired, 2FA verification required opens. Enter the Verification code from your authenticator app and click Confirm. You will not be asked again for 15 minutes. Success: Rule created!.

Without an event, Save is disabled. Without an action, saving reports Add at least one action!.

Limit an event to one status

1. In the wizard, choose Status changed for orders or Return status changed.
2. A Trigger on status (pre-filter) field appears with the hint React only when changing to this specific status. This field is absent for other events, including Return BOK status changed.
3. Type part of a name in Search status... and select a status. Entries look like name (ID: number).
4. To react to every status change, leave -- None (no filter) -- selected.
5. Save the rule. Changing the event clears the pre-filter because order statuses and return statuses come from different catalogs.

Configure a “Cyclic” rule — repeated while an object stays in a status

1. In the wizard, select Cyclic: return in status (the Returns group) or Cyclic: order in status (the Orders group).
2. An Interval field appears below the event, initially showing Choose how often. Its hint says First run one interval after entering the status, then every interval. Choose Every 5 minutes, Every 15 minutes, Every 30 minutes, or Every 1 hour.
3. In Return status (or Order status for orders), select the status to watch — or add a Return status condition (for orders, Internal status) with is or is one of. If both are set, they must share a status. The permanent hint beneath the field explains: Choose a status here or in the “Return status” condition — the rule will not run without a status (for orders, the “Internal status” condition). There is no -- None (no filter) -- option here; clear the field with its cross.
4. Add the remaining conditions and actions as for any rule. There is no Run once toggle — the rule repeats by design. The rule’s total waiting time — Wait before execution in Action settings and the Wait action — must be shorter than its interval.
5. Save. An enabled rule (Rule is active) cannot be saved without an interval: Choose how often the rule should run! appears at the top and under Interval. It also cannot be saved without a status: beneath the status field appears A cyclic rule needs a status: select it in “Return status” or its condition; if both are set, they must share a status (for orders, “Order status” and “Internal status”). If the wait is too long, the system refuses with Rule save error: A cyclic rule must finish waiting before its interval expires: shorten the wait or choose a longer interval. The same text appears under Interval. A field-level message clears when you change the related value. A disabled rule can be saved without these checks; they run when you enable it.

How it works and what to watch for is described in Cyclic — a rule that repeats automatically below.

Change the event on an existing rule

1. Open the rule by clicking its row or the pencil in the actions column.
2. Change the event under Trigger.
3. If the new event belongs to another area and the rule already has conditions or actions, the Change trigger domain? dialog explains: The new trigger belongs to another area. Conditions and actions that do not work there will be removed; those that work with any trigger will remain. Confirm with Change and clear, or cancel with Cancel.
4. Click Save changes. Its color and label change when the dialog contains unsaved edits. Confirm with a 2FA code. Success: Rule updated!.

Check that the event actually triggers the rule

1. Trigger the event on a real object, for example by changing an order status.
2. Return to the rules list. Under Runs (24h), the rule gets a badge for run count and one for success rate. Click either to open that rule’s log for today.
3. Alternatively, open Advanced → Automation logs, expand filters, set Workflow to your rule (entries look like #id - name) and Date range to Today.
4. The Event column shows what triggered each entry. Click the eye (View details) to open Event data, the raw data provided to the rule.
5. No entry means either the event was not triggered or the listener process has not refreshed yet. Wait and try again (Automation pitfalls).

Orders

Order downloaded · Status changed · Order paid · Order cancelled · Order edited · Order items changed · Invoice issued · Tracking number assigned · Shipment created · Courier status changed · Order added to queue · Picking completed · Sorting completed · Packing started · Packing completed · Cart put away · Replenishment required · Status congestion · Order stuck in status

Returns

Return status changed · Return received · Return assessed · Return completed · Return rejected · Return BOK status changed · Return status change failed · Refund sent · Return created

Return created fires once when an employee opens a return in the scanner or creates one manually (a problematic return). For a scanner-created return, the order and expected return are already linked, so the rule can immediately check whether it is an undelivered parcel and whether the order was paid. A manual return has no order: it counts as unpaid, not cash on delivery, and has no order status, so conditions checking false or explicitly selecting NO are met. Use Has order to limit a rule to returns linked to orders. Returns created through the ERP API, consolidated parcels and bulk returns do not send this event.

Documents

Document created · Document approved · Document cancelled · Document status changed

Products and catalog

Product created · Product changed · Product activated · Product deactivated · Stock changed · Below minimum stock · Out of stock · Item returned to stock · Price changed

Warehouse and stocktaking

Location flagged for checking · Stocktake scanned · Stocktake approved automatically · Stocktake escalated · Stocktake corrections reverted

Consolidated parcels

ZRS parcel created · ZRS parcel status changed

An event triggered because NOTHING happened

All other events follow a change: someone pays, changes status or puts away a cart. Order stuck in status is the opposite: it fires because nobody has touched an order for a while.

• The scan runs every 15 minutes and reads rules to know what to look for. Add a Hours in current status condition (how long is too long) and usually Internal status (which status to watch). Without a threshold, it defaults to one hour.
• It signals for a specific order. Its action can move or notify about that order or change its status. This differs from Status congestion, which says that some number of orders are sitting in a status and does not carry any particular order.
• An order is reported once per threshold window, not at every scan. If it leaves the status and returns, it is reported again.
• Orders that entered the status more than 30 days ago are skipped: they are archive records, not alerts. The first scan after rollout will not flood anyone with old items.

Status congestion checks the whole status at once, for example: nothing has changed in KFS_Test for 10 minutes, so move everything to KFS_Error.

• Every 90 seconds the scan counts orders or returns in the status selected by the Blocked status (model + status + min. minutes) condition. A rule without a status is not counted and will never fire.
• It fires when that count has not changed for the specified number of minutes. Each object entering or leaving the status restarts the timer. An empty status does not fire.
• If the action moves nothing and the count remains unchanged, the event returns only after another full window, not at each scan.
• If the move action has Only returns without a BOK status enabled, the scan counts only those returns. Returns being handled by BOK do not keep the congestion active.
• The action first records what is in the status, then moves items in turn. An order or return that leaves the status during this time, for example because SubLinker moved it on, stays where it is.

Cyclic — a rule that repeats automatically

Cyclic: return in status and Cyclic: order in status run a rule at the configured interval for every return or order that remains in the watched status. For example, check every 15 minutes whether an ERP credit note has arrived for a return, until it appears or the deadline passes (the Check ERP credit note action, Actions — what a rule can do).

• Set the Interval in the trigger step: Every 5 minutes, Every 15 minutes, Every 30 minutes, or Every 1 hour. Without an interval, the rule can only be saved disabled and cannot be enabled. In the rules list, the When column shows a clock, interval, and status, for example Every 15 min: return in KFS_Created (if the status is selected only by a condition: Every 15 min: return in status); the wizard footer shows the same information.
• Specify the Status in the Return status / Order status field under the event, or with a Return status / Internal status condition (is, is one of). If you set both, they must match — the rule watches only their shared statuses. The system will not enable a rule with no status or no shared status; it can only be saved disabled, and will never run.
• The first run happens after one interval from the moment the object enters the status, then repeats at each interval. If an order or return leaves and later re-enters the status, the timer starts again. Setting a return to the same status again does not reset its timer.
• This event does not react to entering the status itself — use Status changed or Return status changed for that. You can combine them: one rule checks on entry, and a second, timed rule retries.
• Run once is unavailable: a cyclic rule is designed to repeat, so the wizard does not show this toggle and the system will not save an active rule with it enabled.
• Any wait in the rule must finish before the interval expires, or the next run would start before the previous one finishes. The system sums all waits — Wait before execution on each action and the Wait action — including waits on actions configured to run If previous succeeded or If previous failed. The system will not save an active rule whose total wait is longer than its interval.
• History: new cyclic rules retain history for 14 days because they can create an entry for every watched order or return at each interval. Daily cleanup deletes all older entries for cyclic rules, including Succeeded and Waiting, which are kept for other rules to protect Run once.
• Orders and returns that entered the status more than 60 days ago are skipped — they are archive, not a queue. Only customer returns count; returns from wholesaler parcels do not.
• One sweep (every minute) handles at most 300 orders and returns, at most 100 from one company; the rest are handled in the next sweep. To prevent the same ones waiting repeatedly, companies are rotated (each sweep starts with a different company), and within a company the objects whose current interval expires soonest go first. A run held up by the limit until its interval ends is dropped; the next run comes at the next interval. Each rule tracks its interval separately. If several rules watch the same return, it receives one event listing the rules whose time has come.
• Sweeps do not overlap: if the previous one is still running, the next is skipped. A sweep that runs out of time stops, and the next one handles the remainder.
• Under Automation logs → Event data, the fields are status_id, minutes_in_status, hours_in_status, and timer_rule_ids (the rules due in that sweep).

Watch the load. The system scans watched statuses every minute, regardless of the interval. Sweep cost grows with the number of orders and returns that entered the status during the last 60 days, not with how many remain in it. Use these events for statuses that orders and returns pass through, not large final statuses reached by every order. For one watched status in one company, a sweep reads at most the 1,500 longest-waiting objects — newer ones wait until older objects leave or reach 60 days. Each run creates a log row (often Skipped — “not yet”). An object that remains in the status but fails the other conditions still gets an event every interval; with Log unmet conditions enabled, each produces an Conditions not met entry (Execution history — what really happened).

Status pre-filter before conditions

For Status changed, Return status changed, and both Cyclic events, the wizard provides an extra field specifying which status triggers the rule. For Cyclic, the field is named Return status or Order status and selects the status the rule watches. This filter is checked before conditions — it is cheaper and clearer than a status condition.

The Return Customer Service status changed event deliberately has no such field.

Practical notes

• Custom events, triggered by a button, are a separate category (Custom events — manually triggered buttons).
• Some events have a built-in delay to avoid a flood when changes happen rapidly. You cannot configure it in the panel.
• A newly added rule may take several dozen seconds to start working because the listener refreshes its list periodically (Automation pitfalls).