Short answer: ShipStation automation rules are a static IF/THEN engine. They fire once, when an order first lands in Awaiting Shipment or On Hold. They evaluate criteria you defined in advance against fields already present on the order. They do not query live rates, do not read multiple line items, do not re-run when an order changes, and do not calculate anything.
Within those boundaries they’re genuinely good, and most shipping operations never hit the walls. This page is for the ones that do. It covers what the rules engine actually does, in the order it does it, and the specific places where it stops — including a few that fail silently.
This is the single most misunderstood part of the system, and it causes more “why didn’t my rule fire” tickets than anything else.
ShipStation applies automation rules when an order imports into or is created in the Awaiting Shipment or On Hold status for the first time. That last phrase is doing a lot of work. Per ShipStation’s own documentation: changes made to orders already sitting in Awaiting Shipment will not trigger automation rules.
What this means in practice:
The rules ran once, at import, against the data that existed at that moment. Everything after that is manual.
There is one escape hatch: Reprocess Automation Rules (Settings → Automation → Automation Rules) re-runs Product Defaults, Service Mapping, and Automation Rules against everything currently in Awaiting Shipment. It’s a bulk manual action, not an automatic trigger. And it is not a clean replay — ShipStation deliberately skips order weight adjustments on reprocess, so a rule that adds 4 oz for packaging won’t add it a second time. That’s the right behavior, but it means “reprocess” and “import” aren’t the same event, and rules that depend on adjusted weight can behave differently between the two.
Why this matters: any decision that depends on information arriving after the order does — a rate that changed, a stock level that dropped, a forecast for a delivery date three days out — is structurally outside what the rules engine can see. It isn’t a gap in the feature. It’s the shape of the feature.
ShipStation runs its automation layers in a fixed sequence. Getting this wrong is the second most common cause of rules that “don’t work”:
Then, within automation rules, ShipStation processes your rules top to bottom in list order, and later rules can override earlier ones.
Two consequences worth internalizing:
Rules have dependencies, and the order is yours to manage. ShipStation’s docs give the canonical example: a rule that adds carrier-specific insurance will fail if the shipping service hasn’t been set by an earlier rule. Same with Rate Shopper — the rule that sets package dimensions must sit above the rule that applies the Rate Shopper strategy, or the rate gets calculated against nothing.
Tag-based rules are order-dependent too. The common workaround for a lot of limitations is “tag it, then key off the tag.” That works, but only if the tagging rule runs first. Product tags and customer tags are applied before any automation runs, so those are safe. Tags applied by an automation rule are only available to rules below it in the list.
This is the biggest structural limitation in the product, and it’s the one most likely to be the actual reason your setup isn’t working.
The Item Name, Item SKU, and Warehouse Location criteria only evaluate orders with a single line item.
That’s not a bug or an edge case — it’s documented behavior. The same caveat applies when you use a Saved Filter as criteria: if the filter keys on SKU, item name, or warehouse location, it will only match single-item orders.
ShipStation support has confirmed the underlying reason in community threads: automation rules cannot parse multiple SKUs or item names when they run. A rule that says “if the order contains SKU-1234, use the insulated box” will simply not fire on an order that contains SKU-1234 and anything else.
For a lot of businesses this is invisible, because most orders are one item. For anyone with a real mix of basket sizes, it means the rules engine is quietly opting out of your multi-item orders — which are usually the expensive, complicated ones you most wanted automated.
The standard answer is product tags, and it’s a better answer than it first sounds. It’s worth understanding properly, because it will solve more of your problem than you expect.
Tag the product record. ShipStation applies product tags to any order containing that product at import — before any automation runs. Same for customer tags. So by the time your rules evaluate, every order is already labelled with the attributes of everything in it, multi-item or not. The single-line-item wall doesn’t apply, because you’re no longer asking about line items. You’re asking about tags on the order.
Then you build on top of that, and there’s real expressive room here:
Tag includes FRAGILE AND Total Weight is Greater Than 20 is a perfectly good rule, and it works on a twelve-item order.Does Not Include lets you express “contains no perishables,” which is often the rule you actually want.Used well, this covers a large fraction of what people initially think they need SKU criteria for. If you’re reading this because a SKU rule isn’t firing, go build the tag version — it’ll probably work, and it costs you an afternoon.
Now the part that doesn’t bridge.
A tag answers a yes/no question: is this thing in the order? What it can’t answer is what, exactly, is in the order?
Specifically, tags give you set membership but not the bill of materials. The order is tagged FRAGILE — but is that one wine glass or nine? It’s tagged FRAGILE and HEAVY — is that one fragile item and one heavy item, or one item that’s both? A tag is flat. It carries no quantity, no per-item dimensions, no relationship between items.
Three things follow, and they’re the real ceiling:
Quantity is invisible. You can see the order’s total quantity and total weight, but not that it contains six of SKU-1234 and four of SKU-5678. “Six units of the 10 oz jar” and “four units of the 16 oz jar” can produce identical total weights and require completely different boxes.
Combinations explode. Criteria lines are AND-only with no OR and no nesting. Every additional attribute that interacts with the others multiplies your rule count, and each rule’s behavior depends on its position in the list. Three tags that genuinely interact is manageable. Six is a system nobody on your team can reason about, failing silently when someone inserts a rule in the wrong slot.
The tags need maintaining forever. Every new SKU needs correct tags applied on day one, or it silently falls through every rule keyed to them. This is fine at 200 SKUs with one person who owns it. It’s a standing liability at 2,000 across a catalog that changes seasonally.
So the honest summary: tags convert a line-item parsing problem into a boolean classification problem, and boolean classification is enough for most rules. What survives is anything that needs to know the actual contents — quantity, per-item dimensions, how items combine.
Which, unfortunately, is exactly what packing decisions need. You cannot cartonize from a tag. Fitting items into a box requires knowing which items, how many, and how big — the precise information a tag throws away by design. Same for splitting an order across boxes, and same for comparing flat-rate options against standard rates, which depends on whether the contents physically fit in the carrier’s box.
The rules engine’s boolean logic is deliberately simple:
;).So (A AND B) OR (C AND D) isn’t expressible as one rule. You write it as two rules, and now you own the ordering and the override interactions between them. This is manageable at five rules. At fifty, it’s a system nobody on your team fully understands, and the failure mode is silent.
There’s also no arithmetic. Criteria compare a field to a value you typed. The engine can’t compute density, can’t derive dimensional weight, can’t compare two fields to each other, can’t sum anything across line items. Total Weight is Less Than 16 works. Weight divided by volume is greater than X is not a thing the engine can express.
And there’s no external data. Criteria read fields already on the order. There is no action to call an API, fetch a forecast, look at your ERP, or check a carrier’s current rate. Whatever isn’t already in the order record doesn’t exist as far as the rules are concerned.
The failures that cost real money are the ones that don’t announce themselves.
A blank criteria or action kills the whole chain. ShipStation’s troubleshooting docs are explicit: a rule with a missing criteria or missing action will fail — and will also cause every subsequent rule to fail to run. One half-finished rule someone left saved at position 3 can silently disable positions 4 through 40. There’s no warning banner. Orders just start shipping wrong.
Weight rules need weight at import. Weight-based criteria only work if the selling channel actually sent a weight in the order data. If it didn’t, the criterion evaluates against nothing and the rule doesn’t fire. Product Defaults can backfill weight before rules run, which fixes this — but only for products you’ve maintained defaults on.
Custom packages require a carrier and service. You can’t apply a custom package by itself. The Set Carrier/Service/Package action sets all three together. If you want to set dimensions without pinning a carrier, you use Set Package Dimensions instead — and then the package’s name never appears on the order, which breaks any downstream process (or human) that reads the package name off the order screen.
Overrides are invisible. If two rules both set the service, the lower one wins. Nothing tells you the first one ran and got overwritten. The order activity log in Order Details will show you what applied, but you have to know to go look.
Don't Import the Order is irreversible. Once applied, the order record is gone from your account and cannot be recovered. ShipStation recommends building the rule with a harmless action first (Set Custom Field 1, or Add an Internal Note), confirming it matches only what you intend, and only then switching the action to Don’t Import. This advice is worth following exactly.
In rough order of likelihood:
The order activity log in the Order Details window is the ground truth for what actually ran. Reprocessing rules against Awaiting Shipment is the fastest way to test a fix — remembering that weight adjustments won’t reapply.
ShipStation’s automation rules are a well-built static rules engine, and for a huge number of shipping operations they are completely sufficient. Set the service by weight and zone. Route by store. Tag by product. Hold pre-orders. That’s most of what most brands need, and it works.
The limits are the limits of the category. A static IF/THEN engine evaluating pre-declared conditions against a snapshot of an order at import cannot:
Those aren’t oversights. Building any one of them would mean building a different kind of product than the one ShipStation is, and ShipStation is deliberately a horizontal platform serving 130,000+ businesses. It’s not their job to know your SKUs.
If you’re hitting these walls, the honest options are three:
That third option is what String does. We sit above your ShipStation account, read each order, apply the rules that the native engine structurally can’t express, and update the shipment before anyone touches it. Your team keeps the ShipStation screen they already know.
If you’ve read this far because a specific rule isn’t doing what you need, tell us what you’re trying to do — we’ll tell you honestly whether it’s a rules problem you can fix yourself or something that needs a layer above.
Do ShipStation automation rules run when an order is updated? No. Rules apply when an order first enters Awaiting Shipment or On Hold. Later changes to an order already in Awaiting Shipment do not re-trigger rules. Use Reprocess Automation Rules to manually re-apply them to orders in Awaiting Shipment.
Why do my SKU-based automation rules only work on some orders? The Item Name, Item SKU, and Warehouse Location criteria only evaluate orders with a single line item. Multi-item orders are skipped. Use product tags instead — tag the product record, and ShipStation will tag any order containing it at import, before rules run. This works on orders of any size and solves most cases.
What can’t product tags do? Tags tell you whether something is in an order, not what’s in it. They carry no quantity, no per-item dimensions, and no information about how items combine — so an order tagged FRAGILE could be one wine glass or nine. You can pair tags with order-level criteria like total weight or total quantity, which covers a lot. What it can’t cover is any decision that needs the actual bill of materials, which includes every packing decision: cartonization, box selection for mixed orders, and splitting an order across boxes.
Can ShipStation automation rules use OR logic? Partially. Multiple values inside one criterion are treated as OR (semicolon-separated for typed values). Separate criteria lines are always AND. There is no OR between criteria lines and no nesting — you need multiple rules, sequenced correctly.
Can automation rules check live shipping rates?
Not directly. Rules are static and don’t query rates. ShipStation’s Rate Shopper feature does check live rates and can be applied via the Set Rate Shopper action — but it compares services for a package you’ve already defined, and it’s plan-gated.
Why did all my automation rules stop working at once? Most likely a rule with a blank criteria or blank action. ShipStation fails that rule and every rule below it in the list.
Is there a limit to how many automation rules I can create? ShipStation doesn’t publish a hard cap. The practical limit is comprehension — because rules run in list order and later rules override earlier ones, large rule sets become difficult to reason about and fail in ways nobody notices.
Can automation rules read data from outside ShipStation? No. Criteria evaluate fields already present on the order record. There’s no action to call an external API or service.
Most ShipStation stores are — oversized boxes, rate programs that never get checked, and packaging that doesn't match what's actually being shipped.
String builds custom packing, rate, and shipping logic directly into your ShipStation setup, so every order ships at the real lowest cost without manual
review.
Book a free shipping audit
We'll show you exactly what's costing you, and whether String can fix it.