# Unroutable orders

"Unroutable" means that an order was created and could not be assigned to a facility for fulfillment.

{% hint style="info" %}
Unroutable orders can be monitored and manipulated in the [Order view of Backoffice](https://docs.fulfillmenttools.com/documentation/backoffice/network-view/orders).
{% endhint %}

## Reasons for unroutable orders

There is a chance that the DOMS is not able to route an order due to:

* No facility can fulfill the requirements of a particular order
* Misconfiguration of the [DOMS](https://docs.fulfillmenttools.com/documentation/by-pillar/advanced-order-routing)

Especially in case of a [same day order](https://docs.fulfillmenttools.com/documentation/store-operations/carrier-management/carrier-features-and-requirements#same-day-delivery) it is very likely that an order cannot be routed at all because there is no facility available which can fulfill the request of the consumer on that very day.

## **Using a fallback facility**

A fallback facility can be defined if the user does not want to perform a manual process in case an order could not be routed. If a fallback facility was defined, orders are assigned to this facility in case they get the state “not\_routable”. Such a facility might be a “super-warehouse” which has nearly infinite capacity (or might get a fast replenishment).

One can only define a facility as a fallback facility if the state of the facility is “online”. Once a facility was defined as a fallback it cannot be set to “suspended” or “offline” anymore.

It is possible (at a later stage) to define more than one facility as a fallback facility. The order which cannot be routed initially is then routed to the fallback facility chosen by the [DOMS toolkit](https://docs.fulfillmenttools.com/documentation/by-pillar/advanced-order-routing/doms-toolkit). For this routing all fences are ignored and only the active ratings are used to find the best facility.

#### Timeframe for routing to fallback facility

In the routing config one can also set a timeframe after which the not\_routable order is routed to its final destination. In this timeframe the order is displayed in the “Unroutable” tab in the Order overview. If the timeframe is set to 0 (which is also the default value), the order is directly routed to the fallback facility.

## FAQs

<details>

<summary>How to deal with unroutable orders?</summary>

You have the following options to deal with unroutable orders:

1. **Assign a new facility for fulfillment:** Assign an order to a specific facility by ignoring any configured fences. A possible scenario might be to route a Same Day order to a given facility, change it to a Standard Delivery Order (see Carrier change) and fulfill it. It is possible to assign the partial or the whole order.
2. **Changing consumer address** enables the user to handle situations where the shipment could not be delivered and a second attempt (with another address) should be performed.
3. **Trigger a new DOMS decision:** Rerun the routing process to re-evaluate whether a facility now exists that can fulfill the order. This might come in handy when a misconfiguration of the DOMS has been fixed and all orders should be processed in a regular manner.
4. **Canceling an order** cancels all corresponding Pickjobs of an order. It is possible to cancel the partial order or the whole order.
5. **Reroute a specific order** triggers a reroute decision for this selected order. It might be, that the order gets successfully routed or the routing attempt again fails and the order remains unroutable.
6. **Reroute all unroutable orders** triggers the same routing like described above, but all orders are taken into account. You find this feature in the three-dot menu in the header of the table.

   <figure><img src="https://content.gitbook.com/content/Lrrr5jgTsDuR38gNJIrm/blobs/ygxJsjDh3ArOCFGGDB7B/image.png" alt=""><figcaption></figcaption></figure>

</details>

<details>

<summary>How to set up a tenant-wide fallback facility via API?</summary>

Go here to get more details on the [routing configuration REST API](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#put-/api/configurations/routing).

```
{
      "action":"ModifyGlobalRoutingConfiguration",
      "stopRoutingAttemptsAfterTime":"PT0H0M",
      "fallbackFacilityConfiguration": {
          "active": true,
          "facilityRefs": ["89f6d7f3-88ec-4653-96fd-c5b3476c46ce"],
          "fallbackAfterTime": "PT0H0M"
      }
}
```

</details>

<details>

<summary>How to set up a tenant-wide fallback facility via Backoffice?</summary>

![](https://content.gitbook.com/content/Lrrr5jgTsDuR38gNJIrm/blobs/9vkP8cbQTkB1HFGcxr10/image.png)

</details>

<details>

<summary>Will an order become unroutable if no facility can fulfill it in case of a <a href="../../store-operations/picking#short-pick">short pick</a>?</summary>

No, if "[blacklistedassignedfacilities](https://docs.fulfillmenttools.com/documentation/by-pillar/reroute#blacklisting-a-facility)" is set to `true`, the order will stay in the last routed facility. Alternatively, users can define a [fallback facility](#using-a-fallback-facility), that the order will then be directed to. If the settings are not set to `true`, our systems will try to reroute the order to another facility.

</details>
