Rule editor

Business rules are created and edited in the Backoffice. Each rule type has its own page in the Admin sidebar (Shipping costs, Carriers, Payment methods, Incentives, Transaction costs). This page explains the key concepts you will encounter in the rule editor.

Creating a rule

To create a new rule:

1. Navigate to the relevant rule type page in the Admin section of the Backoffice sidebar (for example Shipping costs or Incentives)
2. Click Add rule
3. Give the rule a name using the pencil icon in the top left
4. Add subrules to define conditions and actions

Rule structure

Each rule in the editor has:

• A rule name (editable with the pencil icon)
• A hit policy toggle in the top right corner: first or all
• A channel scope, limiting the rule to specific channels (see below)
• An Add subrule button to add new rows to the decision table
• A Save button

Subrules

Each subrule is a row in the decision table. It has a name, a set of conditions and a set of actions. Subrules are evaluated from top to bottom.

You can reorder subrules by dragging the handle on the left side. The order matters when the hit policy is set to first because the engine stops at the first matching subrule.

Conditions (IF)

The IF section defines when the subrule matches. Each condition consists of:

• An Item dropdown that selects which field to evaluate (for example "Order subtotal" or "Order delivery address country")
• A Condition dropdown that selects the comparison operator (for example "equals", "greater than" or "contains")
• A Value field for the comparison value

You can add multiple conditions to a single subrule using the "Add condition" button. When a subrule has multiple conditions, an and/or toggle controls how they combine:

• And means all conditions must be true for the subrule to match
• Or means any one condition being true is enough

Leaving a condition empty matches any value.

For threshold conditions, use GreaterThanOrEqualTo rather than Equals. Equals 2 matches exactly two, so a customer who orders three matches nothing.

Aggregate on order item conditions

When the Item is "Order items", an Aggregate dropdown decides what is counted:

Aggregate	Counts	A value of 2 means
Count	Order lines	Two different products
Total quantity	Pieces	Two pieces, either one product with quantity 2 or two products with quantity 1
Total price	Summed line value	Two euros of matching product value

Ordering the same product twice does not create two lines

The cart merges a repeated product into one line with a higher quantity. A condition using Count GreaterThanOrEqualTo 2 does not match a customer who buys two of the same product, because the count is still 1.

Match the aggregate to how the promotion is phrased. For "when you order N pieces" use Total quantity. Use Count only when you mean N different products.

User type

The User type condition accepts two values:

• Contact for B2B/company users
• Customer for B2C/individual users

These values are case-sensitive and must match exactly as shown.

Attribute conditions

Product, user and company attributes can be used as conditions. When referencing an attribute, always use its full name. Shortened names will not match.

Correct	Incorrect
PRODUCT_WEIGHT	WEIGHT
PRODUCT_SIZE	SIZE
PRODUCT_STOCK_QUANTITY	QUANTITY or STOCK_QUANTITY

Product attribute nesting

Product attribute conditions use a nested structure:

1. Set Item to "Order items" with Aggregate = Count, Condition = GreaterThanOrEqualTo, Value = 1
2. Set Subitem to "Product Attributes" with Aggregate = Count, Condition = GreaterThanOrEqualTo, Value = 1
3. Add nested conditions using the and/or toggle:
   • Attribute Name equals the full attribute name (for example PRODUCT_WEIGHT)
   • Then the attribute value condition (Attribute decimal value, Attribute text value or Attribute enum value)

User and company attribute nesting

User attributes follow the same pattern but start at Item = "User Attributes" (without the Order Items wrapper). Company attributes start at Item = "Company Attributes".

Enum value operators

When using enum attribute values as a condition, four operators are available:

Operator	Behavior
All	Every attribute value must match the provided value
Contains	At least one attribute value must match the provided value
Some	At least one attribute value must match the provided value (same as Contains)
None	No attribute value should match the provided value

Matching values by attribute type

The value condition to pick depends on the attribute type:

• Enum attributes use Attribute enum value with the operators above
• Text attributes use Attribute text value. Match both Attribute text value language (for example NL) and Attribute text value values with Contains. Text values are stored once per language, so matching the value on its own can behave unexpectedly
• Number attributes use Attribute decimal value with the numeric comparison operators

Actions (THEN)

The THEN section defines what happens when the conditions match. The available action fields vary by rule type:

• Shipping costs produces an action (set shipping costs) and a price
• Carriers produces an action (set carrier to selectable) and a carrier ID
• Payment methods produces an action (set payment method to selectable) and a payment method ID
• Incentives has the widest range of actions (see below)
• Transaction costs produces an action (set transaction costs) and a cost value

For the full output schema per rule type, see Rule types.

Hit policy

The hit policy determines how the engine handles multiple matching subrules. It is shown as a first / all toggle in the top right corner of the rule editor.

Policy	Behavior
First	Stops at the first subrule that matches (top to bottom). Only that subrule's outputs are returned
All	Evaluates all subrules. Every matching subrule's outputs are collected and returned

Use first when subrules are mutually exclusive or prioritized. For example, shipping cost rules typically use first because only one shipping cost should apply.

Use all when multiple results should stack. For example, carrier and payment method rules typically use all because multiple options should be available for the customer to choose from.

Hit policy applies within one rule

The first and all toggle controls how subrules are evaluated inside a single rule. It does not combine results across separate rules. When two rules of the same type both match, only one of them is applied.

Keep alternatives and tiers as subrules of one rule, where the hit policy gives you explicit control, rather than splitting them across separate rules and expecting the results to add up.

Channel scope

A rule can apply to every channel or only to the channels you select. The scope is set on the rule rather than on individual subrules, so it covers the whole decision table.

When a cart or tender is evaluated, only rules whose scope includes its channel are considered. A rule with no channels selected applies to every channel in the tenant, so rules built before channel scope existed keep applying everywhere.

Use this to run different shipping costs, carriers, payment methods or incentives per storefront without duplicating that logic into conditions on every subrule.

Incentive actions

Incentive rules support the following actions:

Action	Description
Add product to bonus items	Adds a product to the order as a bonus item (for example a free sample)
Give discount to order item	Applies a discount to specific order items that match the conditions
Give discount to order total	Applies a discount to the order total
Add valuepoints to order	Awards value points to the order
Set shipping costs	Sets shipping costs on the order. Useful for applying shipping discounts through incentive rules that are triggered explicitly in the Sales Hub
Set transaction costs	Sets transaction costs on the order. Same as shipping costs, useful for explicit incentive-based overrides

The last two actions (set shipping costs and set transaction costs) overlap with the dedicated shipping cost and transaction cost rule types. The difference is that dedicated rules are evaluated automatically on every change, while incentive rules with these actions are only applied when incentives are triggered. In the Sales Hub this means a sales rep can explicitly apply a shipping discount as part of a quote or order negotiation.

Incentives are not recalculated when you change lines in the Sales Hub, unlike the other rule types. To check an incentive rule there, apply incentives on the quote explicitly after each change.

Repeat toggle (incentives)

Incentive subrules have a Repeat toggle on the action. It controls whether the action fires once per order or once per qualifying item. Repeat applies only to the discount and bonus item actions: give discount to order item, give discount to order total and add product to bonus items.

• Repeat off: the action fires a single time when the subrule matches. Use this for a flat discount or a single bonus item
• Repeat on: the action is applied for each qualifying item, so the result scales with the quantity ordered. Use this when a discount or bonus item should grow with the number of matching items

Example: a bonus item that scales with quantity

To add one bonus item for every unit of a product ordered:

1. In the IF section, set Item to "Order items" with Total Quantity, Condition = GreaterThanOrEqualTo, Value = 1. This checks the quantity on the order line
2. In the THEN section, set the action to Add product to bonus items and select the bonus product
3. Turn the Repeat toggle on

With Repeat on, adding the product to the cart with quantity 4 adds 4 bonus items. With Repeat off, a single bonus item is added regardless of the quantity ordered.

Fallback rows

The last subrule in a table is typically a fallback with a condition that is always true, for example "Order subtotal is greater than or equal to 0". This ensures the subrule always matches if no earlier subrule did.

This is useful for shipping cost rules where you want a default rate when no specific country or carrier condition applies.

See also

• Business rules overview for how rules apply at runtime
• Rule types for output schemas and practical examples