Updated
Short answer: ShipStation automation rules are a static IF/THEN engine. Classic rules fire once, when an order first lands in Awaiting Shipment or On Hold. Some accounts now have a redesigned Automation Rules screen that groups rules into named workflows, each with its own trigger type, which adds triggers beyond order import. Either way the engine evaluates criteria you defined in advance against fields already present on the order: it does not query live rates, does not read multiple line items, and does not calculate anything.
Within those boundaries they’re genuinely good, and most shipping operations never reach their edges. This page is for the ones that do. It covers what the rules engine actually does, in the order it does it, and the behaviour worth knowing about before you build on it — including a few cases where a rule silently does nothing.
This is the single most misunderstood part of the system, and it causes more “why didn’t my rule fire” tickets than anything else.
Check which of these two your account has before you rely on any of it, because the answer changes the section below. Across our own customer base we currently see both.
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 — “if an automation rule exists to add or subtract weight, reprocessing automation rules will NOT add or subtract the weight again” — 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.
Some ShipStation accounts now show a redesigned Automation Rules screen, and the structure is worth getting straight before the trigger list, because it explains what does and doesn’t change.
A workflow is a named container with one trigger. Inside it sits an ordered list of automation rules — the same rules, evaluated the same way, top to bottom. The trigger is the single kick-off for the whole chain, not something attached to each rule. So you no longer have one list that fires at import; you have several lists, each with its own starting gun.
The default workflow is called Order Import Workflow, triggered by Orders imported — the classic behaviour, unchanged. Alongside it you can create workflows on other triggers. I have confirmed three: Tag added, Tag removed (two separate options, not one), and a schedule.
Those are the ones that matter, because between them they remove the single-moment constraint above.
A tag applied later in the day, by a person or by another rule, can set work in motion rather than just recording a fact. Tag removed is the more interesting half of that pair and the one people miss: taking a tag off an order is how a hold gets cleared, how an exception gets marked resolved, how a picker signals that something is ready. Those are all moments where a person on the floor has decided something, and until now nothing downstream could act on the decision.
A schedule trigger means something can happen at a fixed time of day rather than only at the moment an order landed — the shape of a cutoff, or a release that should happen once the day has got far enough along.
I have not found this documented anywhere in ShipStation’s help centre, and the term “Workflow Settings” in their documentation refers to something else entirely — Create Label button defaults, Quickship and Scan to Verify. So treat the naming here as descriptive rather than official. What I can tell you is what I have seen in customer accounts.
That is a genuine change to what is automatable, and it is worth checking for before you build a workaround. The class of problem it addresses is anything where the blocker was timing rather than logic — where you knew exactly what should happen, and the obstacle was that the only moment anything fired had already passed. A tag applied by someone on the floor at eleven in the morning can now do work, rather than just recording a fact for a person to act on later.
This is rolling out gradually. Some accounts have it and some don’t, so look in Settings → Automation → Automation Rules in your own account rather than assuming from a screenshot or from what a colleague at another company has. Check which trigger types your account actually offers, too — the ones above are what I have verified directly, and there may well be more.
Worth being precise here, because it is easy to over-read.
A trigger decides when logic runs. That is a different question from what the logic can see and express once it does run.
So a new trigger genuinely solves timing problems — anything where the blocker was that nothing fired after import. What a trigger cannot do by itself is widen the vocabulary: reading a live rate, fetching tomorrow’s forecast for the destination, querying stock in an ERP, summing dimensions across line items, or working out which carton a particular set of items fits into are all questions about what the engine can evaluate, not about when it starts.
Timing and capability are two separate limits. Worth being clear which one you are actually hitting before you decide what to do about it, because they have different answers.
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. On accounts with the newer screen, read that as top to bottom within a workflow: the sequence above is what happens once a workflow’s trigger has fired.
Two consequences worth internalizing:
Rules have dependencies, and the order is yours to manage. ShipStation’s documentation gives 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 this 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 same list. On the newer screen there is a way around this, since a tag change can trigger a separate workflow rather than having to be read further down the same one.
This is the most consequential piece of engine behaviour to understand, and it’s the one most likely to be the actual reason your setup isn’t doing what you expect.
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 behaviour: “Automation rules using the Item Name, Item SKU, and Warehouse Location criteria options will only apply to orders containing a single unique line item (the quantity of that line item does not matter).” 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.
Worth separating this from the Product Defaults restriction, because they are not the same rule and the two get conflated. Product Defaults require a single line item at a quantity of one. The SKU criteria above require a single line item at any quantity. Six of one SKU is fine for a SKU rule and disqualifying for Product Defaults.
The reason is that the criteria resolve to one item’s field, and an order with several line items has no single value to compare. 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, those criteria simply do not evaluate the 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 where the boundary actually sits:
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 documentation is explicit: “Leaving blank criteria or actions will cause an automation rule to fail, and will also cause all subsequent automation rules to fail to run as well.” 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 fields already on the order cannot:
The newer Automation Rules screen adds to the “can” column rather than this one: on accounts that have it, a workflow can run off a tag being added or removed, or on a schedule, rather than only at import. That is a real improvement, and it is worth checking whether it solves your problem before assuming you need anything else. What it doesn’t change is the four above, because those are properties of the criteria and actions rather than of the trigger.
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 a very large and varied merchant base. 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 logic that is specific to your operation, 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, the self assessment runs on two standard ShipStation exports and never leaves your browser. Plenty of rule problems are fixable inside ShipStation without anything above it.
Do ShipStation automation rules run when an order is updated? Classic automation rules don’t. They apply when an order first enters Awaiting Shipment or On Hold, and later changes to an order already sitting there do not re-trigger them; Reprocess Automation Rules re-applies them manually in bulk. Accounts with the redesigned Automation Rules screen can also run a workflow off a tag being added, a tag being removed, or a schedule. That is rolling out gradually and is not documented, so check your own settings.
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’s troubleshooting guide is explicit: leaving blank criteria or actions “will cause an automation rule to fail, and will also cause all subsequent automation rules to fail to run as well.”
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.
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.