Published
Yes, and this is the automation most operations should build first. It is quick, it is durable, and unlike the SKU-based rules people usually reach for, it works on every order rather than a subset.
ShipStation’s automation rules criteria reference lists the order-level fields a rule can evaluate. The ones that matter for service selection:
The important property of that list is what it does not have. The Item Name, Item SKU and Warehouse Location criteria only apply to orders with a single line item. None of the fields above carry that restriction, because they describe the order rather than something in it. A weight rule works on a twelve-item basket exactly as it works on a one-item basket.
That is why weight and destination rules are the reliable half of the rules engine.
Worth reading that criterion name carefully, because it is the one place this gets loose. The list offers USPS Zone. It does not offer a UPS zone or a FedEx zone, and there is no generic distance band.
Carriers each map distance their own way. So the moment you use that criterion to make a decision about a UPS or FedEx service, you are using one carrier’s distance model as a proxy for another’s. For most domestic ground lanes the two move together closely enough to be useful, and near the boundaries they do not. A postal code that sits at the top of one USPS zone can land either side of the line on another carrier’s chart.
This does not make the criterion useless. It makes it an approximation, and it is worth knowing which of your rules are built on one. If a rule matters and it keys on zone for a non-USPS service, check it against a sample of real addresses rather than assuming the bands line up.
The classic pair, for US domestic volume:
That takes about five minutes and covers a large share of domestic parcels for a lot of brands. Add zone or state conditions where your carrier mix genuinely differs by distance, and add the residential-commercial split if you ship FedEx, where Ground and Home Delivery are separate services and using the wrong one attracts a surcharge.
Two limits, and they are the same two that apply to every static rule.
The rule encodes a rate card, not a rate. Automation rules compare a field to a value you typed. They do not query live rates, so the answer they give is only as good as the pricing model you built the thresholds from, and it goes stale when carriers reprice. That is not a reason to avoid them. It is a reason to know when you last checked them. Setting a Rate Shopper strategy by rule covers the alternative, and the method for building the model when you need it.
Weight has to be present at import. A weight-based criterion evaluates against whatever the selling channel sent. If the channel sent nothing, the criterion has nothing to compare and the rule does not fire. Product Defaults can backfill weight before rules run, but only for products where you have maintained them.
There is a middle option that gets most of the way there, and it works with the approximation rather than against it.
Instead of using zone to pick a service, use it to pick a Rate Shopper configuration. The rule sets the strategy and live rates decide the service inside it:
The zone approximation is doing much less work in that version. It is no longer deciding what you ship, only which pool of services competes for the order, and the actual choice inside that pool is made against live rates for the real parcel and the real destination. A zone that is one band off shifts an order into the neighbouring pool rather than onto the wrong service outright.
It is not exact. It is considerably better than a static service assignment, it costs two rules and two configurations, and it degrades gently when the approximation is wrong. Building and routing Rate Shopper configurations covers how to set the collections up, including the parts that catch people out.
If you are far enough in to be building a matrix of weight thresholds and zone bands, it is worth stopping to ask what the matrix is for. It is for finding the cheapest service that still arrives when you said it would. That is exactly what Rate Shopper does, and it does it with better inputs than the matrix has.
A weight-and-zone rule is a model of carrier pricing that you built, from a snapshot, and now own. Rate Shopper is not a model. It takes the weight and dimensions on the order, asks the carriers what they would actually charge for that parcel to that address, and applies the winner.
Every input the rule approximates, Rate Shopper has exactly:
| The rule | Rate Shopper |
|---|---|
| A weight threshold you chose | The actual weight and dimensions on the order |
| A USPS zone standing in for the carrier’s own chart | The real destination address |
| The rate card as it stood when you priced it | Today’s rate, on your accounts |
So the weight-and-zone matrix is a hand-built approximation of a thing the platform will do properly, per order, for free. The five-minute version above is worth having. A fifty-rule version is a second job.
The better place to put that effort is into the Rate Shopper configurations themselves, built around what the customer was actually sold: one configuration per shipping option on your storefront, each holding the services that honour that promise, routed by the requested service rather than by a zone guess. Configuring Rate Shopper well covers building the collections and routing to them.
Weight and destination rules do not disappear in that setup. They stop choosing the service and keep everything else. They are how you route an order to the right Rate Shopper configuration, as above. And they still drive every action that was never about picking a carrier: adding insurance above an order value, requesting signature confirmation for particular destinations, tagging international orders so somebody checks the customs fields.
Keep the matrix only where Rate Shopper genuinely cannot go: an account or region without it, or volume where the box is not known until someone packs the order, in which case no rate shopper helps either and the problem is upstream of rating altogether.
String builds and maintains logic like this inside existing ShipStation accounts — cartonization, rate selection, batching, inventory-aware holds, cold chain rules. No dashboard, nothing for your team to learn.
Typically for operations past 6,000 orders a month with a dedicated fulfillment team.
