Automation pitfalls

Step by step

Audit a rule for actions that do nothing

1. Open Tools → Automation → Rules and open the rule.
2. Review the cards in the Action column. Three names show a warning: Notify manager about stocktake, Generate ERP documents and Test: write to JSON.
3. If you find one, remove it with the card’s trash icon and use a working alternative. For notifications, use Send notification (Email/SMS/In-app) from Works with any trigger. Test actions appear in the selector only for administrators, but may exist in rules saved earlier for any user.
4. Click Save changes and confirm with the code in 2FA verification required.
5. To check history, open Advanced → Automation logs, filter Workflow to this rule and Result to Successful. Open an entry with the eye icon and read Action results: actions from this list reported success there despite doing nothing.

When a rule does not work: check in this order

1. In the rules list, check the toggle in the second column. Enabling it shows Rule enabled.
2. If the toggle is grey and disabled, and there is a lock beside the name, the rule is managed by a setting. Tooltips say Generated from an integration setting. Read-only here. and This rule is managed by an integration setting — change it there. For buyer emails, the message is This rule is managed by customer order page settings — change it there. Clicking the row shows the same message instead of opening the wizard.
3. If the rule was just added, wait several dozen seconds (up to a minute for product and stock events), then trigger the event again.
4. Open Advanced → Automation logs, set Workflow to the rule and Date range to Today. No entry means the event never arrived; CONDITIONS_FAILED means it arrived but failed a condition.
5. To see which condition failed, open the wizard’s Advanced panel in the actions column and check Log unmet conditions (description: Log when conditions are not met). New rules have it on by default; for older rules, enable it, save and trigger the event again. The log details then show Condition results with Expected and Actual columns.

Faster: Test rule in the rule list evaluates each condition separately without waiting for another event (Create and organize rules).

6. If no company rules work and you have not changed anything, the engine may have been disabled globally. Pressing a custom event button then shows Could not trigger the event. The panel does not reveal the underlying reason, so ask the deployment administrator.

Reorder rules without surprises

1. Open Tools → Automation → Rules.
2. Clear filters. When a filter is active, a red Clear filters cross appears on the left of the toolbar. Increase the page size in the list footer until the whole section fits on one page.
3. The group heading shows the number of rules in the entire section. If an information icon appears beside it, only part of the section is on the page. Its tooltip says This page shows {shown} of {total} rules in this section. Rules can be moved within the page.
4. Drag the row using its handle (vertical dots in Execution order) or use Move up / Move down in the actions column. On a phone only the arrows work; there is no drag handle.
5. Saving the order also requires 2FA verification required. A rejected save moves rows back and shows Could not save execution order: ….
6. The number means execution order. The column tooltip says Execution order. Rules for the same event run one after another, starting with the lowest number. Reordering renumbers the whole section, but affects execution only relative to rules for the same event.

1. Three actions report success without doing anything

This is the most costly trap because history shows a green result:

• Notify manager about stocktake writes a log entry. Nobody is notified.
• Generate ERP documents is a stub. No document is created.
• Test: write to JSON writes nothing; it is a diagnostic action.

Use Send notification for notifications (Actions — what a rule can do).

2. Call URL works now, but has strict rules

The Call URL action, which used to fail every time, now sends a real request (Actions — what a rule can do). Three things may catch you out:

• The address must be public. A service on a local network or a cloud metadata address is rejected; redirects to those destinations are also rejected (redirects are not followed).
• Any response outside 2xx is an action failure. A rule set to stop on error will stop.
• An unrenderable body template stops the action instead of sending raw {{ ... }} to the partner.

3. Loops stop quietly, but saving now warns you

A rule can trigger another rule, which can trigger another. The chain has a hard depth limit. If it is exceeded, the event is discarded and the system creates an issue about the loop. The issue now lists the names of rules listening for the discarded event; previously it showed only the event and object, which were already known.

After saving a rule, the system checks for a loop and shows one warning at the top:

• This rule closes a loop: A → B. The chain will be cut off at the 10th hop. Rules may wake each other up. This is not forbidden: a loop whose action repeatedly writes the same value stops by itself.
• A + B write different values to the delivery method field — they will overwrite each other. This arrangement will never stabilize and needs to be broken. It is what an operator sees as someone constantly changing the delivery method.

Saving is never blocked; the warning appears alongside the save confirmation.

The check knows status order. If the second rule listens for entry into a specific status and the first moves orders elsewhere, it will not report a loop. Warnings that cry wolf teach people to ignore them.

Review older rules for trigger/action combinations that might loop. If the cause is hard to identify, ask NOXTI support to help diagnose it.

The only action that avoids retriggering itself is Modify order: it does not write a value when it is already the same. Likewise, changing an object to its current status does not save or emit an event.

Compare the history of successive executions for the same object. Repeated changes to the same fields can indicate rules triggering one another.

4. Run once does not always mean once

It fails in two cases:

• An event without object context has nothing to remember, so the rule runs every time, even with the option selected.
• History cleanup: successful-execution history enforces this option. Once old entries are cleaned up, the rule may run again on an object from months ago (Execution history — what really happened).

5. A new rule does not work in its first second

The listener refreshes its rule list periodically. A newly added rule can take several dozen seconds to become active; product and stock events may take up to a minute.

Before deciding the rule is broken, wait and trigger the event again.

6. Two actions at the same position break branches

Actions can be given the same position, and the system does not prevent it. Their result is then combined, making If previous succeeded and If previous failed behave unpredictably.

For branches, give every action its own unique position.

7. Reordering applies across the area

Dragging reorders every rule in the area, but only order within the same event matters. In a filtered or paginated list, you can move only the rows currently shown (Create and organize rules).

8. Wait pauses everything behind it

A rule with a Wait action holds the object, and later rules wait behind it. An hour of silence after a rule with a reminder may look like a blocked queue, but is a scheduled delay (How a rule runs — queue, retries and waiting).

What the interface does not provide

• Undo for changes made by a rule — actions have no rollback; reverse their effects manually.
• History retention control — contact NOXTI support to request a change.
• Event delay setting — built in and not editable.
• A Skipped result filter — skipped entries exist but cannot be selected in the filter.