The Order Management Rules (OMR) engine for Rule Sets has been fully rebuilt in techSHIP 2025, enabling you to visually build more complex logic with improved flexibility and clarity.

 

NOTE: This article focuses exclusively on Rule Set OMRsClient-level and Client Template-level OMRs remain unchanged. OMRv1 and OMRv2 refer to the previous and new versions, respectively.

 

This guide highlights the key UI changes introduced in OMRv2.

 

NOTE: To learn about the OMRv1 logic, refer to How to Set Up Portal Global OMR Rules [Step-by-Step Guide]. While the article is based on the previous OMR engine, it remains a valid reference until the updated version is published.

 

The following video offers a quick tour of the OMRv2 features covered in this article:



This article is divided into the following sections

  1. OMR v1 vs. v2: Conversion Process
  2. Trigger
  3. Clients
  4. Visual Rule Builder
    1. Conditions
    2. Actions
    3. For Each Loops
    4. Decision Tree
  5. Import and Export


 

NOTE: For a full overview of all new features, see: What's New in techSHIP 2025: A Guide to the Latest Features [Information].

 


I. OMR V1 VS. V2: CONVERSION PROCESS



While techSHIP 2025 is in beta, each portal can be accessed through either the previous or the new interface. Thus, both OMRv1 and OMRv2 rules are visible in both interfaces, but each rule can only be managed in a single version:

  • OMRv1 rules can only be edited in Legacy, and appear in techSHIP 2025 with a conversion icon.
  • OMRv2 rules can only be edited in techSHIP 2025, and appear in Legacy with a link to techSHIP 2025.


   
techSHIP LEGACY
techSHIP 2025
OMRv1
OMRv2

 

NOTE: Line-level conditions are evaluated differently in OMRv2:
  • OMRv1: The rule is triggered if any order line matches the condition.
  • OMRv2: The rule is triggered only if all order lines match.

OMRv2 also introduces the For Each Loop block at line level, which can be used to replicate the original "any line" behavior. This process automatically applies the For Each Loop when converting line-level conditions. See the For Each Loops section below for more details.

 

WARNING: Converting an OMRv1 to OMRv2 cannot be undone. 

 




II. TRIGGER



In OMRv1, each rule could be triggered by a different event. In OMRv2, the entire rule set is triggered by a single event, defined in the rule set's main properties.





III. CLIENTS



In OMRv2, assigned Clients are visually managed through the Clients tab, allowing for easier overview and modification.

 

NOTE: If no Clients are assigned, the rule applies to all Clients within the Portal.

 



IV. VISUAL RULE BUILDER



From the Actions tab, you can visually build the rule logic using the Add Action button to insert Actions, Conditions, or For Each Loops and assemble them into a Decision Tree.

 

NOTE: The Decision Tree is built step by step, following the logic flow you define. For best results, we recommend outlining your rule structure in advance.

 


OMRv2 introduces a modular, atomic structure for all its building blocks: Actions, Conditions, and line-level For Each Loops. Each of these steps operates independently and defines its own properties.


i. Conditions


Conditions in OMRv2 are structured as logic trees, where operands are grouped under logic operators (e.g., ANDOR). This allows you to build complex evaluation paths visually.



Each operand also defines its own properties, enabling mixed logic conditions

 

NOTE: Line-level conditions are evaluated as true only if all lines in the order match the criteria. To apply logic when any line matches the criteria (as in OMRv1), place the condition inside a For Each Loop. See the For Each Loops section for details.

 

 For example, you could create a condition that checks whether:

  • the total order quantity is 10, and

  • all lines contain a SKU that includes AA.



ii. Actions


OMRv2 follows the same atomic logic for Actions. Each action defines its own properties and scope, enabling actions at both the line and order level.



iii. For Each Loops


OMRv2 introduces For Each Loops, which let you iterate through each line of an order and apply nested Actions and Conditions on a per-line basis.


Inside a loop, Conditions are evaluated for each line individually. Therefore:

  • A nested order-level Action will be applied to the entire order if any line matches the condition.
     
    WARNING: When branching inside a loop, avoid applying order-level Actions to the same field on both the True and False paths. Because the loop iterates through every line, the field's final value will be overwritten and determined by the result of the last line evaluated.

     

  • A nested line-level Action will only be applied to the specific lines that matched the condition.


 

NOTE: Line-level conditions outside a loop are only true if all lines in the order match.

 
For example, if you need to perform an order-level Action when any SKU is flagged as a Dangerous Good (DG), place the condition that checks the SKU inside a For Each Loop:



iv. Decision Tree


As you add For Each Loops and nest Conditions and Actions, a Decision Tree is formed. This visual representation helps you understand the rule's logic flow, cover edge cases, and quickly identify where actions should be placed.


For Each Loops appear as yellow diamonds, with an arrow indicating the iterative flow of the block. 


Conditions appear as dark cyan trapezoids, with the left branch representing the True path and the right branch representing the False path.


Actions are color-coded based on their position in the tree:

  • Green for those on the left (True) branch.
  • Red for those on the right (False) branch.
  • Blank for those not linked to a Condition.


The following example illustrates a complete Decision Tree that, for all orders:

  • Sets signature required (order-level Action located at the end of the Decision Tree), and
  • applies the corresponding terms, depending on the order's country (order-level Conditions) and,
    • for Canada, if any line item (For Each Loop)
    • is flagged as DG (line-level Condition), then
      • apply the Canadian DG Terms (order-level Action), and also
      • add a "Handle with care" instruction to that line (line-level Action).



Click any + icon to add a For Each Loop, Action, or Condition at that location.


 

NOTE: For Each Loops cannot be nested inside themselves.

 


V. IMPORT AND EXPORT



You can Import and Export OMRv2 rules from the Actions tab using the corresponding buttons.



Exported OMRv2 files use the YAML format, allowing you to edit them externally and re-import into any OMRv2 rule set.

 

WARNING: Take into account that:
  • Importing a file completely overwrites the current OMR.
  • The import process does not validate rules for conflicts. Overlaps or contradictions may cause unexpected behavior.

 

Exported OMRv1 files have limited compatibility. You can import them into OMRv2 using the Convert From OMR V1 Format option. During this process, only rules whose trigger matches the current rule set will be imported.

 

WARNING: If an OMRv1 file is listed and available for conversion, as described in the previous sections, use the conversion process instead of direct import.