# 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](/documentation/backoffice/network-view/orders.md).
{% 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](/documentation/by-pillar/advanced-order-routing.md)

Especially in case of a [same day order](/documentation/by-pillar/store-operations/carrier-management/carrier-features-and-requirements.md#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](/documentation/by-pillar/advanced-order-routing/doms-toolkit.md). 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="/files/Ev57m8ytKwy9XbeFUxtz" 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>

![](/files/Ub7I91XujRHJo40SuDN5)

</details>

<details>

<summary>Will an order become unroutable if no facility can fulfill it in case of a <a href="/pages/98cc084ae540d603ec0424c3c563a7c8e3655fda#short-pick">short pick</a>?</summary>

No, if "[blacklistedassignedfacilities](/documentation/by-pillar/advanced-order-routing/reroute.md#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>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.fulfillmenttools.com/documentation/by-pillar/advanced-order-routing/unroutable-orders.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
