Shopify order routing can send work to a warehouse that looks right on paper but makes the order harder to fulfill. Shopify’s latest developer update allows order routing Functions to rank locations across multiple fulfillment groups in its unstable APIs. For merchants with multiple fulfillment locations, that creates a useful question: where should groups share a location preference, and where do they need different treatment? Here’s how we’d evaluate the change before committing development time or touching live routing.
What changed in Shopify order routing?
In its November 5 developer changelog, Shopify announced that order routing Functions can now apply a location ranking across multiple fulfillment groups in the unstable Function APIs.
A shared location ranking expresses the same location preference across multiple fulfillment groups. It does not, by itself, mean those groups become a single shipment. A preference for a warehouse is different from a guarantee that the warehouse can fulfill everything.
That distinction matters. Merchants tend to judge routing through outcomes: which warehouse received the work, whether the customer got separate parcels, and what the delivery cost. Developers also have to consider the groups presented to a Function and how its ranking interacts with the rest of the routing setup.
Our view: this update is worth investigating when your business wants a consistent location preference across groups. It is not a reason to replace working routing just because a new API capability exists.
Unstable means evaluation, not a production deadline
The release explicitly concerns unstable APIs. It does not establish a stable release date or require merchants to migrate.
Ask your developer to inspect the current schema and confirm the supported behavior in a development environment. Before planning production deployment, verify availability in the intended API version and eligibility for your app and store. The announcement alone is not a complete implementation specification.
Start with the warehouse decision, not the Function
Before writing code, describe the decision your operations team wants to make. “Prefer the main warehouse” is too vague. Prefer it under what circumstances? What happens when a retail location has stock but needs that stock for walk-in customers?
Consider a hypothetical apparel merchant with a central warehouse and store-based fulfillment. A basket contains outerwear and an accessory, and the routing input presents multiple fulfillment groups. The merchant may want each group to prefer the central warehouse when it can fulfill the relevant items.
A common preference could make sense here. But if the accessory is available only at a store, the shared ranking cannot create warehouse stock. Nor should the team assume that applying the preference will combine the shipments.
Now consider a product that needs specialist handling. If it must ship from a particular facility, that requirement needs protection. A general warehouse preference must not override an operational restriction.
Define what makes a location eligible separately from what makes an eligible location preferable. Then ask the developer which parts the routing extension can express and which belong elsewhere in the fulfillment setup.
When shared Shopify order routing rankings make sense
The strongest use case is repeated business logic. If different groups should follow the same warehouse preference, expressing that preference consistently may make the implementation easier to understand and maintain. That is a potential engineering benefit, not evidence of cheaper shipping.
Central warehouse preference
A merchant might want the central warehouse to take precedence because it has a dedicated dispatch team, while stores fulfill only when necessary. Shared rankings are worth exploring if that preference genuinely applies across the affected groups.
The trade-off is concentration. Sending more work to the preferred warehouse can create pressure there. Your routing policy needs to reflect operational capacity, rather than treating an established warehouse hierarchy as permanently correct.
Regional consistency
A merchant may also want groups within an order to follow the same regional location preference. The business reason might be a known delivery service or a more predictable dispatch process.
Check which inputs the Function actually receives before promising regional logic. Do not design a policy around live carrier quotes or warehouse capacity data without confirming how that information reaches the decision.
Who should skip custom development? Merchants whose existing routing settings already express the desired behavior, and businesses that rarely face a meaningful choice between fulfillment locations. Custom code adds ownership and testing obligations. It needs to solve an observable problem.
Write down exceptions before choosing a ranking
A location preference becomes dangerous when everyone remembers the default and nobody remembers the exceptions. We’d ask operations to document these cases before development starts:
- Restricted products: identify items that require a particular facility or handling process.
- Store stock protection: explain when stock must remain available for local customers.
- Dispatch constraints: record circumstances in which the preferred location cannot meet the delivery promise.
- Unavailable locations: define acceptable behavior when the usual warehouse cannot take the work.
This document should describe business requirements, not pretend that every requirement is a supported Function input. The developer’s next job is to map each requirement to verified platform behavior.
Where the required information is unavailable, simplify the policy or change the surrounding process. A routing rule based on stale assumptions can be worse than an uncomplicated default that the warehouse team understands.
Test routing decisions against actual order patterns
A successful Function execution is not enough. The useful test is whether its decision matches an approved business outcome.
Use representative historical basket patterns in a development environment, with customer details removed. Include orders that went smoothly as well as those that required manual reassignment. For each scenario, record the relevant stock position and the expected location preference before running the test.
Your test set should include:
- Groups whose items are all available at the preferred warehouse.
- A group that cannot be fulfilled at the preferred warehouse.
- Items with a location-specific handling restriction.
- A normally preferred location that is unavailable.
- Groups that legitimately need different preferences.
- An order pattern that currently causes manual intervention.
For each case, inspect the ranking and then follow the downstream fulfillment outcome. Keep those observations separate. A correct ranking can still produce an undesirable shipment pattern because another constraint governs fulfillment.
Ask operations to approve the results alongside the developer. A test can pass technically while sending work somewhere the dispatch team cannot handle it.
Measure the result without promising fewer parcels
Shared ranking is a routing capability. Parcel reduction is a possible business outcome that must be demonstrated.
Before a production change, establish how often staff manually reassign fulfillment work and why. Track split shipments separately. Include actual fulfillment cost where your reporting supports it, rather than treating the preferred location as automatically the cheapest.
Compare similar order patterns after the change. Differences in stock availability can distort the result: if the main warehouse receives replenishment during the evaluation, routing may appear to improve even when the new logic contributes little.
We’d also examine dispatch performance. A policy that reduces reassignment but overloads the preferred warehouse may leave customers worse off. Decide beforehand which operational outcome would justify keeping the change and which would trigger a rollback.
Plan for failures before enabling enforcement
Give the implementation a named owner and document how to restore the previous routing setup. Keep the approved business policy beside the technical configuration so support staff can distinguish an intended exception from a defect.
During an incident, check Shopify Status, which provides platform status information and directs merchants to detailed status for their store. Use that as one diagnostic input. A platform incident does not prove your Function is responsible, and an operational status page does not prove your custom logic is correct.
Then inspect the affected order’s routing context and the app’s available diagnostics. Avoid repeated manual reassignment until someone understands whether the problem is missing inventory, an unsuitable preference, or an execution failure.
For an unstable API feature, the immediate action is a development investigation with documented results. Keep the live routing policy unchanged until supported deployment and business behavior are clear. That is a better use of this release than rushing experimental logic into a busy dispatch operation.
Takeaways
- Shopify’s new capability applies a location ranking across multiple fulfillment groups in unstable Function APIs.
- A shared ranking does not guarantee a combined shipment or lower fulfillment costs.
- Separate location eligibility from preference, and document exceptions before development.
- Test representative orders and verify production support before changing live routing.
Sources
- Order routing functions can now rank locations across multiple fulfillment groups in the unstable Function APIs.
- Shopify Status
Want this handled for you?
We're a Shopify Premier Partner and this is the work we do every day: performance, CRO, and store builds that pay for themselves. Book a free store review and we'll show you the three fixes we'd ship first.
Frequently asked questions
What changed in Shopify order routing in November 2026?
Shopify announced that order routing Functions can apply a location ranking across multiple fulfillment groups in the unstable Function APIs. Merchants should verify stable API support before planning a production implementation.
Do shared location rankings combine Shopify shipments?
Not by themselves. A shared ranking expresses a common location preference across groups. Inventory availability and other fulfillment constraints still affect whether items can ship together.
Should every Shopify store build custom order routing?
No. Custom development is worth evaluating when existing routing cannot express a documented business requirement. Stores whose current settings work well may gain little from the extra maintenance.
How should merchants test a Shopify order routing Function?
Use representative order patterns in a development environment and define the expected outcome beforehand. Include unavailable stock, restricted products and location exceptions. Inspect both the ranking and the downstream fulfillment result.
