Workflow conditions — every listed condition must be met

The condition list uses AND — use a group for OR

Conditions listed one after another are joined with AND. Every condition must be true.

Evaluation stops at the first condition that is not met.

How to create an alternative

There are three ways, from simplest to most flexible:

1. Use the is one of operator in one condition for “status is A or B or C”. This is enough when all alternatives use the same field.
2. Use Any of the following — a group containing several different conditions. The rule continues if at least one is met. This is OR.
3. Create two rules with the same event and actions. This is now needed only if the alternatives should run different actions.

“Any of the following” condition group

Choose it from the condition list like any other condition. Its value field contains a small list. Add alternatives with Add alternative; each one is a regular condition row with its own condition, operator, and NOT toggle.

• An empty group is never met. A half-built group will not let a rule “for everything” through.
• The group’s own NOT switch means “none of the following”.
• Alternatives cannot be nested. A group inside a group is not offered in the selector and is ignored if entered externally.
• An alternative that cannot be checked (deleted condition or invalid value) counts as not met; the remaining alternatives are still evaluated.

The group is available for every trigger family: orders, returns, documents, and products.

What you can check

There are dozens of conditions, grouped by topic:

Integration-capability conditions are easy to overlook. They prevent a rule that works on one channel from generating action errors on another.

Fulfilment warehouse for line items

An order does not have one warehouse. The fulfilment warehouse is set on each item separately (the same field shown on the order card and used to decide which picking queue receives that item). That is why there are two conditions:

• All products from warehouse is met when every item comes from the selected warehouse. Use it as a gate for a rule tied to one location, such as that location’s courier or documents.
• Any product from warehouse is met when at least one item comes from the selected warehouse, even if the rest ship from elsewhere. Use it for split orders that need handling at a particular location.

Both support is one of, so one rule can cover several warehouses at once (“everything from the warehouses we are picking today”).

There is no “not all items are from here” operator. Use NOT on All products from warehouse.

All order items have shipped

Has tracking number is met if at least one parcel for the order has a tracking number. For orders shipping in several parcels—for example, some goods from your warehouse and others from a wholesaler (Wholesaler — someone else stores and ships your goods)—that is too early to treat the whole order as shipped.

All order items shipped (yes/no) is met only when every unit of every order item is in a parcel with a tracking number, including your parcels and ones the wholesaler sent for you. Your items are counted based on what was put into each box during packing. A packed box without a tracking number has not left; its items are still pending.

• A parcel shipped directly by the wholesaler with a tracking number (for example, Halmar) counts for every item from that wholesaler’s warehouse—even if its list does not name all products or we failed to recognize one.
• Other parcels with tracking numbers but no items assigned to them (for example, older shipments) count their own items: a parcel from your courier for a wholesaler warehouse counts items from that warehouse; your own parcel counts items from your warehouse.
• Items from a virtual warehouse do not hold up the condition; they do not leave in a parcel.
• An order with no items or no outgoing parcel does not meet the condition.

Typical use: Parcel created trigger, All order items shipped condition, and Change status action to a shipped status.

Composite conditions: “Product in order” and “Address and customer”

These two conditions have their own editors instead of a regular value field because they ask about an attribute, not one specific field:

• Product in order — SKU, EAN, name, product, category, catalog, ABC class.
• Address and customer — city, street, postal code, region, company, tax ID, email, phone, person, pickup-point name and city.

Fill them in three steps: Match by (the attribute), Comparison, and Value. The operator above the editor stays at “is true”; the comparison is configured inside.

Comparisons: is, is one of, contains, starts with.

Is one of accepts a list of values. The field becomes a chip list (type and press Enter) or a multi-select when the attribute has a dictionary. One rule can replace several rows in an “Any of the following” group: “tax ID is one of <B2B company list>”, “SKU is one of <promotion list>”, or “city is one of <metro-area list>”.

A few details:

• Comparisons are case-insensitive, including list values.
• Address and customer compares buyer details the same way as search and saved filters: it ignores Polish diacritics and accents (“Łódź” = “Lodz”), ignores hyphens and spaces in postcodes (“00-950” = “00950”), and normalizes phone numbers with or without a country code (“+48 600 700 800” = “600 700 800”). A rule and saved filter therefore return the same result for the same order.
• Blank values in a list are ignored, and an empty list is never met. A half-filled condition never lets a rule “for everything” through.
• Attributes that are identifiers (product, category, catalog) offer only “is” and “is one of”; “contains 12” would also match 120 and 512.
• Some attributes are checked on both sides: tax ID and phone can be on the address or customer record; SKU and EAN can be on the order item or its matched catalog product. A value list checks both.
• There is no comparison for “the order does not contain SKU X”. Use the condition’s NOT switch.

Undelivered parcel (returns)

Undelivered parcel is met when the return is for a parcel sent to the customer that the courier failed to deliver—refused, not collected in time, or returned to sender—and that came back to the warehouse. The customer never had the goods, so this return often needs different handling from one sent back by a customer. The system recognizes it in either of two ways:

• The return is linked to the advance notice the system creates for the failed delivery (visible among parcels in transit).
• The latest courier status for the parcel sent to the customer is Delivery failed.

Return order: paid and status (returns)

A rule triggered by a return (Events — what starts a rule) can select only conditions from the Returns group. Two of them check the order that the return came from:

• Order from return: paid — checks whether the order is paid: marked as paid, or COD where the courier collected the money (one parcel sent to the customer has a delivered status). A refused, uncollected, or still-in-transit COD parcel is unpaid. The order condition Paid checks only the paid marker, which imports do not set for COD orders, so the two conditions can differ. The answer is also shown by the Paid / Unpaid chip in the return header.
• Order from return: status — the order’s internal status, selected from the same list as Internal status. Operators: is and is one of.

Example: Return created + Undelivered parcel + Order from return: paid → send the return for Customer Service review, where they can decide whether to refund or reship.

Operators

Operators depend on the value type:

For courier-status conditions, the operator works as any of the saved statuses matching.

Relative time: “older than” / “newer than”

A date compared with a fixed calendar date becomes stale as the rule ages: six months later, “ordered before March 1” means something different. Date conditions therefore also accept a relative window:

• Choose is older than or is newer than.
• Instead of a calendar, two fields appear: amount and unit (minutes, hours, days). For longer periods, enter days—for example, “older than 30 days”.

“Ordered more than 3 days ago” means the same thing every day of the year. “Newer than” uses a window ending NOW, so a future date (planned shipment) is not in it. An incomplete window (amount without a unit) is a configuration error: the condition is false, even with NOT enabled.

How long an order has been in its current status

Hours in current status returns the full hours since the order entered the status it is in now. If the order has never changed status, the clock starts at creation.

It is most often used with the Order stuck in status trigger (Events — what starts a rule), but works with every order trigger, including rule tests.

Negation

Each row has its own NOT switch, applied last.

When an opposite positive operator exists, the operator list hides the negative version. That prevents a confusing double negative such as “NOT (is different from)”, which means the same as “is equal to”.

An invalid condition counts as not met

If a condition cannot be checked because data is missing or has an unexpected value, it counts as not met, and the rule does not run. Doing nothing is safer than acting on guesswork.

The execution history shows conditions not met (Execution history — what really happened).

Conditions are checked again after a wait

A rule with a delay checks its conditions again after waiting. If the situation changed meanwhile, the rule may not run even though it was valid at the start. That is intentional (How a rule runs — queue, retries and waiting).