> For the complete documentation index, see [llms.txt](https://docs.fulfillmenttools.com/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fulfillmenttools.com/documentation/backoffice/network-view/routing.md). # Routing strategy {% hint style="info" %} This article focuses on using Backoffice. For API and customization information, see the [Advanced Order Routing section](/documentation/by-pillar/advanced-order-routing.md). {% endhint %} In order routing, you can define a routing strategy to meet your consumers' needs best. Based on the configured strategy, fulfillmenttools decides which warehouse or store to fulfill the order from. The initial view shows the configured strategy as a flow diagram. {% hint style="info" %} You can create categories and then assign them to the nodes to make the flow diagram easier to view. Click the **Set categories** button to do this. {% endhint %}

To edit the routing strategy, we recommend reviewing the basic configuration first. To do this, hover over the **Basic configuration** box and click the edit icon. This opens the node configuration modal. {% hint style="info" %} More information on the routing strategy can be found in the [Routing strategy article](/documentation/by-pillar/advanced-order-routing/routing-strategy.md). {% endhint %} ## Routing node configuration The routing node configuration lets you define your routing strategy. The basic configuration is the first gate an order has to pass through. You can then create subsequent gates for the order to pass through to get to the best facility for the order. {% hint style="info" %} For orders to be routed to a particular facility, the order type (click-and-collect or ship-from-store) the facility can accept must be set in the facility settings. This can either be done in the [network view](/documentation/backoffice/network-view/facilities.md#service-type) or the [facility view](/documentation/backoffice/facility-view/facility.md#service-type). {% endhint %} ### Fences Fences define which routing options are eligible for an order. If a routing option doesn't meet a criterion, it's discarded and is no longer available for selection. Click **Add fence** to open the list of predefined fences. Select the required fences, then activate them. Fences configured in a preceding node are inherited by all subsequent nodes, together with their activation status. Inherited fences are listed as inherited rules. You can also remove fences from the list. Removing a fence applies to all subsequent nodes that inherited it. In addition to predefined fences, you can create custom fences. See the [Custom routing rules article](/documentation/by-pillar/advanced-order-routing/doms-toolkit.md) for more information.

The example below shows the fence configuration of a node that isn't the basic configuration: * **Country borders** is inherited as active from a preceding node and is overridden in this node, which sets it to inactive. * **Facility capacity** is added in this node and is activated. * **Order completeness** is inherited as active from a preceding node. * **Preselected facilities** is added in this node and is activated.

### Ratings Ratings determine the preferred routing option when multiple options can fulfill an order after [fences](https://docs.fulfillmenttools.com/documentation/by-pillar/advanced-order-routing/complex-routing-with-combinatorics/fences) filter out facilities. Ratings never exclude a routing option. Instead, they only change the ranking order of the routing options. See the [Ratings article](/documentation/by-pillar/advanced-order-routing/complex-routing-with-combinatorics/ratings.md) for more information on how the ranking is calculated. #### **Priority ratings** {% hint style="info" %} Priority ratings are in beta and aren't enabled for all customers, so you might not see this in your Backoffice. {% endhint %} Priority ratings apply to criteria that must always outweigh everything else. The routing option that performs best on the first priority rating wins, regardless of any ratings below it. A lower rating takes effect only when the higher rating ends in a tie. For example, you can rank routing options by delivery speed first, with a second criterion applied only when two options are equally fast. Click **Add priority rating** to open the list of predefined ratings. Select the required ratings, then activate them. Use the drag and drop next to a rating to define its position in the ranking order. You can also configure custom ratings as priority ratings. Click **Create custom priority rating** to do this. See the custom routing rules article for more information. #### **Weighted ratings** Weighted ratings score every remaining routing option. A higher weighting counts for more in the total rating score. Weighted ratings are evaluated only when priority ratings tie or are not configured. Click **Add weighted ratings** to open the list of predefined ratings. Select the required ratings, then activate them. Click **Create custom weighted rating** to configure a custom rating as a weighted rating. Each weighted rating requires a weighting, which is defined with the slider. The weighting determines how strongly the criterion influences the routing decision. To illustrate the relationship between the weighted ratings, the resulting trade-off is shown in blue text below the ratings. Use the **Reference factor** dropdown for trade-offs : * Dynamic**:** The reference is the rating that's currently adjusted with the slider. * A specific rating: The selected rating serves as the fixed reference. All trade-offs are then expressed in relation to that rating, for example, total costs, which allows the remaining ratings to be adjusted accordingly.

#### **Configure with AI** {% hint style="info" %} The Configure with AI feature is in beta and isn't enabled for all customers, so you might not see this in your Backoffice. {% endhint %} The **Configure with AI** button lets you describe your use case to our Sidekick, which will propose a matching configuration. Describe the use case as fully as possible in text. For example: ``` Always prefer the fewest partial deliveries. If several routing options result in the same number of partial deliveries, compare delivery time and total costs. A delivery time that is at least two days shorter justifies up to 3 EUR in additional costs. ``` In this case, the Sidekick could propose the following configuration: * Number of partial deliveries is configured as a priority rating with the highest priority. * Delivery time and total costs are configured as weighted ratings, with their trade-off calibrated so that a delivery time that is two days shorter justifies up to 3 EUR in additional costs. * The number of partial deliveries is therefore always evaluated first, and the routing option with the fewest partial deliveries is preferred, regardless of delivery time and costs. Delivery time and total costs are evaluated only when two or more routing options result in the same number of partial deliveries. Click the **Apply suggestions** buttons to transfer the proposal into the ratings configuration. Then click **Save** for the changes to take effect.

{% hint style="info" %} **Default filter:** Only active fences are displayed. Adjust the filter to show inactive fences as well. {% endhint %} {% hint style="info" %} If you need any help configuring the rules, [contact our Support team](https://ocfulfillment.atlassian.net/servicedesk/customer/portal/1). {% endhint %} ### Order split The first setting you can define in the node configuration is the order split. An order split divides an order into multiple parts, which can then be routed to different facilities. The order is then shipped in multiple parcels. An order split can only be activated for [ship-from-store orders](https://docs.fulfillmenttools.com/documentation/by-pillar/order-management#ship-from-store-order). Since same-day orders often incur high shipping costs, you can configure order splitting to apply only to non-same-day orders. If you deactivate order split, the order must be fulfilled from one facility. See the [Order split article](/documentation/by-pillar/advanced-order-routing/order-split.md) for more information.

### Short pick rules A short pick is when an order couldn't be completely picked. This can happen when some ordered items are too low in stock or out of stock. There are three rule configurations you can set: * Reroute tasks which are completely short picked (0 pick) * Reroute or order split a shipping task after a short pick * Reroute or order split a pickup task after a short pick See the [Short pick section](/documentation/by-pillar/store-operations/picking.md#short-pick) for more information.

### Manual rerouting By activating the manual reroute toggle, you allow someone to manually intervene in an order and reroute it via Backoffice. For more information, see the [Manual reroute section](/documentation/by-pillar/advanced-order-routing/reroute.md#rerouting-reroutetaskmanually).

### Fallback facility A fallback facility can be defined if you don't want to perform a manual reroute in case an order can't be routed. If a fallback facility is defined, orders are assigned to it if they receive the status of `NOT_ROUTABLE` in the routing plan. Such a facility might be a super-warehouse with nearly infinite capacity (or with fast replenishment). You can set up a fallback facility for every node in the routing strategy. If an order is unroutable, it will take the fallback facility of the node where it became unroutable. To do this, activate the toggle, select the fallback facility from the dropdown, and input the amount of time that should pass before rerouting the fallback facility. See the [Fallback facility section](/documentation/by-pillar/advanced-order-routing/unroutable-orders.md#using-a-fallback-facility) for more information.

### Inactivity rules The inactivity rules set the timeframe to trigger an automatic reroute if a picking task has not been started within that time. By default, this timeframe is set to 24 hours after the pick job was created in the facility. You can set different times for different types of tasks. For example, you could set a shorter timeframe for same day orders, as it's imperative that they're picked quickly. See the [Reroute in case of inactivity (time-triggered reroute) section ](/documentation/by-pillar/advanced-order-routing/reroute.md)for more information.

### Unroutable orders An order might not be assigned to a facility (routed) if no available facility passes a specific fence. In such a case, the system retries routing the order whenever another order is passed to the routing strategy. After a configurable amount of time, the order is set to an unroutable state. The default time is 8 hours. See the [Unroutable orders article](/documentation/by-pillar/advanced-order-routing/unroutable-orders.md) for more information. ## Creating new nodes To create a new node in the routing strategy, click the **+** button next to the Basic configuration node. This creates the new node in a deactivated state. Click on the edit icon to input your settings as above. Click the more icon to make the node active. You can then click the **+** button to create the next node, or click the **OR** button to create an if node. ## Node categories Node categories allow a visual representation in the routing strategy. These categories don't affect anything else, but just provide a visual guide for your team. To create a new category, click **Set categories**, then click **Add category**. This will create a new line in the list. Click the color at the start of the line to choose a different color. Then, click the edit icon to change the name of the category. To add a category to the node, select the edit icon on the node, then select the chosen category in the **Condition** section. {% hint style="info" %} You can only add a category to a node if all the required conditions are inputted. {% endhint %}

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.fulfillmenttools.com/documentation/backoffice/network-view/routing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.