Routing strategy
Last updated
Last updated
The routing configuration can be adapted to different levels of complexity based on individual requirements.
In more homogeneous setups — where the logistics network, product portfolio, and sales markets are relatively uniform — a largely standardized routing strategy is often sufficient. In this simpler variant, all orders follow the same routing rules regarding fences, ratings, and order splits. This means, for example, that an order split can either be allowed or restricted for all orders.
Additionally, settings related to the possible consecutive routing decision also apply uniformly to all orders. For example, manual rerouting can be either allowed or restricted for all orders without distinction.
In more complex setups, the 'routing strategy' concept enables differentiation across multiple context-specific routing configurations within the same tenant. In regards to the example above, this means that order splits can, for example, be allowed for orders from the sales channel 'Webshop' while being restricted for orders from the sales channel 'Amazon'.
This also includes distinctions in consecutive routing actions. For instance, manual rerouting could be permitted for orders from the company’s own web shop while being restricted for marketplace orders.
This level of configurability ensures greater flexibility in handling diverse order sources and business requirements.
The basic configuration serves as the foundation of the routing strategy, defining all essential routing settings such as fences, ratings, order split behaviour, and rerouting rules. The basic configuration cannot be deactivated or deleted. All settings defined within the basic configuration are inherited by subsequent nodes but can be overridden or extended at the node level if needed.
For simple and homogeneous setups, the basic configuration is usually sufficient to cover all necessary use cases without requiring additional nodes.
For more complex setups, any number of nodes can be added on top of the basic configuration. Each node defines specific conditions that determine which orders or requests it applies to, along with the ability to override or extend routing rules inherited from the basic configuration or previous nodes.
The conditions within a node can reference any property/attribute of an order or request. When these conditions are met, the system first evaluates whether a subsequent node’s conditions also apply. If so, the process continues with that node. If no additional nodes match, the last positively evaluated node serves as the final aggregation point for the routing configuration. Starting from the basic configuration, all applicable nodes contribute their respective rules based on the described inheritance principle, forming the final rule set that determines how the order or request is routed.
As a fundamental rule, all settings from a previous node are inherited by the next one, ensuring a structured and flexible approach to the routing configuration.
Each node, except for the basic configuration, can be individually activated or deactivated. If a node is in an inactive state, it is skipped during the evaluation of the routing strategy, and its routing configurations are not considered.
Activating or deactivating a node also has implicit effects on any subsequent nodes that are directly linked to it.
Example: If the "Amazon" node is deactivated, the "PRIME" node, which is dependent on it, is automatically set to inactive as well.
In addition to activation and deactivation, nodes can also be deleted. There are two ways to do this:
Deleting a single node: In this case, subsequent nodes shift up to maintain continuity in the routing structure.
Deleting an entire branch: This removes the selected node along with all directly or indirectly connected nodes, effectively eliminating the entire path originating from that node.
In addition to manual activation/deactivation, a timeframe can be configured to automatically activate or deactivate a specific node (and any dependent nodes) at a predefined time. This feature allows for dynamic adjustments to routing strategies based on operational needs.
For example, a specific routing configuration can be set up to handle increased order volumes during peak periods. Once the defined timeframe expires, the node is automatically deactivated, reverting to the default routing setup without requiring manual intervention.
