How a rule runs — queue, retries and waiting

Step by step

Check what a rule actually did

1. Open Advanced → Automation logs. The list refreshes every 30 seconds; the toolbar toggle tooltip is in English: Auto-refresh ON (30s) / Auto-refresh OFF.
2. Expand the filters with Filters (funnel icon) and set Workflow to the rule. List entries look like #id - name; an unnamed rule is labelled No name.
3. Set Date range: Today, Yesterday, 7 days, 14 days, 30 days, or Custom (which shows From and To fields).
4. Under Result, choose Successful, Failed, Partial, Conditions not met, or Waiting. Note that the table shows the raw database code: PASSED, FAILED, PARTIAL, CONDITIONS_FAILED, WAITING.
5. Check Event, Result, Duration and Triggered at columns. A second line, Executed: …, appears under the trigger time; the difference is time spent in the queue or waiting for a scheduled delay.
6. Click the eye icon (View details). A dialog opens with the English title Execution Log #<number>.
7. Read the dialog in order: General information, Timestamps (Triggered at / Executed at), Error message if an action failed, Condition results (a Position / Condition / Method / Expected / Actual / Result table whose last column is a PASS or FAIL badge), Action results, and Event data (two raw JSON blocks).
8. Click Close.

One red entry does not necessarily mean a failure. Transient errors are retried, so check whether a later attempt for the same rule ended as PASSED.

Build a chain of dependent actions

Example: “create a shipment, then send the tracking number”.

1. Open Tools → Automation → Rules and open the rule.
2. On action card 1, choose Create courier shipment and click the hand icon in its header. It should turn red and its tooltip should change to Stop workflow if this action fails. Otherwise the next action may send a number that does not exist.
3. On action card 2, choose Send tracking number, open the gear (Action settings) and set Run when to If previous succeeded.
4. In the newly displayed Track action field, select action 1, shown as #1: Create courier shipment.
5. If the courier needs time to issue a number, set Wait before execution in the same dialog, for example to 5 minutes. The maximum is 1 hour.
6. Close the menu. Summary badges in the card header show the delay and On success (or On failure).
7. Click Save changes and confirm the code in 2FA verification required. Success: Rule updated!.
8. The rule list shows a clock icon with the tooltip Waits up to {time} — rules below start only when this one finishes. This is an upper limit, not a measurement.
9. Test it by triggering the event and checking the log. During the pause the entry has result WAITING; after it resumes, it gets a final result.

Always queued, never immediate

An event does not run a rule immediately. It enters a queue, is picked up, and then executed. The delay is usually small, but not zero; do not build a process that assumes immediate execution.

An event is sent only after the database change is committed, so a rule never sees data that was not ultimately saved.

One object at a time

Rules lock the object, not the rule. Two rules for the same order will not run concurrently; the second waits.

If waiting fails, history shows a skipped entry with an explanation. This is not a rule error.

Actions run in order

Actions run in the configured order. If one fails:

• By default, the rule continues and the failed action is recorded.
• If stop on error is enabled for the action, the rule stops.

This matters for dependent actions. If Create shipment is followed by Send tracking number, enable stopping on error; otherwise the second action may try to send a number that does not exist.

Conditional actions

Each action can run always, if the previous one succeeded, or if the previous one failed. The last option lets you respond to a failure, for example by notifying someone when the courier refuses a request.

Retries

Transient errors — a temporary marketplace outage or database overload — are automatically retried, multiple times. Do not react to the first red entry; check whether a later attempt succeeded.

Permanent errors, such as missing configuration, are not retried.

Waiting

The Wait action (or a delay configured on an action) pauses the rule for up to 60 minutes. The rule is saved in the waiting state and resumed later.

Two things to know:

• Conditions are checked again after the wait. If the situation has changed, the rule may not continue; that is expected.
• Actions already completed are not repeated after resumption.

A rule with a wait has a clock icon in the list showing the maximum wait. It is an upper limit, not a measurement.

Rule-chain limit

A rule can trigger another (Custom events — manually triggered buttons). To prevent loops, the chain has a hard depth limit. If exceeded, the event is discarded and the system creates an issue about the loop (Where issues come from and how they close automatically).

Two rules that keep changing each other’s statuses will never stabilize. The limit stops them but does not solve the problem. Design chains to run in one direction.

The engine can be switched off entirely

A global switch can disable the whole mechanism. With the engine off, automatic rules simply do not run, with no message; manually pressing a button returns a clear error.

If no rules work at all and you have not changed anything, ask the person responsible for the deployment about this switch.