How ShipStation Automation Rules Work: A Complete Reference

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 screen with triggers beyond import — and they run top to bottom in list order, later rules overriding earlier ones. Criteria compare a field already on the order to a value you typed in advance: no arithmetic, no OR across criteria lines, no live rates. Item SKU, Item Name and Warehouse Location criteria skip any order with more than one line item.

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.

When automation rules run (and when they don’t)

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.

Classic automation rules

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:

You edit an order’s weight by hand → no rules re-run
Your marketplace pushes an update to an existing order → no rules re-run
A customer changes their address post-import → no rules re-run
You add a tag manually → no rules re-run against it

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.

The newer Automation Rules screen, where your account has it

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.

What the trigger does and doesn’t change

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.

The order of operations

ShipStation runs its automation layers in a fixed sequence. Getting this wrong is the second most common cause of rules that “don’t work”:

Auto-Routing and Auto-Split (plan-gated; Auto-Routing is US/Canada only; neither applies to manual orders)
SmartFill
Preset Groups
Product Defaults
Service Mapping
Automation Rules — last, and able to override everything above

Position 2 is the one most people do not know is there. SmartFill is enabled by default, and it fills in weight and dimensions by comparing a new order’s items against the two most recent shipments for the exact same combination of items — copying them across only when those two agree. ShipStation states it “applies after Auto-Split and before all other types of automation,” and says the placement is deliberate so that product defaults, service mappings and automation rules all overwrite it. So it fills gaps and loses every argument, which is the right behaviour and also why it is easy to miss: it only shows up on the orders nothing else had an opinion about. Where it sits against the other ways a weight arrives covers it properly.

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.

The dependencies worth keeping in one place

Six constraints account for most of what goes wrong across the layers. Five are documented and one is not, and the difference matters.

Dimensions before Rate Shopper. Documented in ShipStation’s Rate Shopper setup: “The dimensions rule must come first to ensure that all orders generate the appropriate rate.” A rate is only as good as the package it was quoted for, and the four ways a box arrives on an order all have to finish first.
Service before carrier-specific insurance. A rule adding carrier insurance fails if no earlier rule set the service.
A tag before any rule keyed to that tag. Product and customer tags are safe because they land at import. Rule-applied tags are only visible below.
Service Mapping before any rule reading the checkout selection. Mapping runs before rules, so Requested Service (Mapped) is populated by the time the rules evaluate — which is what makes routing an order to the right Rate Shopper configuration work.
SmartFill under all of it. Everything from Preset Groups downward overwrites it, so it is never the reason a value is wrong; it is the reason a value exists at all on orders nothing else touched.
The account rule, which cuts both ways. With two accounts on one carrier, Charge Shipping to My Account clears the order’s service if the selected account does not offer it, so the rule goes after a static service rule. Before a Rate Shopper rule is my own observation rather than documented behaviour — the full reasoning and what is documented on each half.

Which layer owns which decision

The order of operations tells you what runs when. The more useful question when a setup has grown past a handful of rules is where a given decision belongs, and that has a general answer.

Put a decision in the earliest layer that can express it correctly. Every later layer can override an earlier one, and no layer can un-override. So a decision placed too late is invisible to everything downstream of where it should have been, and a decision placed too early gets quietly overwritten by something you forgot you wrote. Earliest-that-works is the rule, not earliest possible.

Layer	Owns	Because
Auto-Routing	Which warehouse fulfils	A fact about stock and geography, settled before anything about the parcel
Auto-Split	Whether one order becomes several shipments	A property you declared on the product, not a judgement about the order
SmartFill	Weight and dimensions nobody else supplied	Inference from your own history; correct to lose every argument
Preset Groups	Shipping and customs values shared by a category	One statement covering many products
Product Defaults	Facts about one product	The narrowest true statement you can make
Service Mapping	What the customer chose at checkout	The only layer that knows what was promised
Automation Rules	Anything about the order as a whole	The first layer that sees the order rather than a product
Rate Shopper, applied by rule	Which service, priced live	The only thing that queries rates
Shipping Presets	Decisions needing a person	Outside the chain entirely, applied at the bench

Two things fall out of that table.

Product-shaped facts do not belong in rules. A box that is a property of a SKU belongs on the product record, where it needs no criteria, cannot get out of sequence, and does not add a row to a list somebody has to reason about later. The instinct to put everything in rules is what produces the fifty-rule setup, and a good share of those rules are usually restating facts about products.

Order-shaped decisions cannot go anywhere else. Product Defaults require a single line item at a quantity of one, so anything that depends on the basket has to be a rule, and rules are the first layer that sees an order at all. That boundary is not a preference; it is where the two halves of the system actually divide.

The single-line-item rule

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 tag workaround, and how far it actually goes

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:

Combine tags with order-level criteria. Order-level fields — total weight, total quantity, order total, destination, residential/commercial — never had the single-item restriction. Tag includes FRAGILE AND Total Weight is Greater Than 20 is a perfectly good rule, and it works on a twelve-item order.
Stop a cascade deliberately. There is a Stop Processing Rules for the Order action, which “stops any automation rules that follow this rule from running on that order.” Useful when an early rule has already made the decision and you don’t want anything below it overriding.
Chain tags across rules. A rule can apply a tag, and any rule below it can use that tag as criteria. That gives you a crude but functional decision tree: rules 1–10 classify, rules 11–30 act on the classification. This is still how it works inside a single workflow — the trigger starts the chain, the list order governs everything after.
Chain tags across workflows, if your account has them. Because a tag change can be a workflow’s trigger, a tag applied at the end of one chain can start another, and a tag applied or cleared by a person hours later starts it just the same. The constraint that classification must sit above action in one list is a within-workflow constraint, not a general one.
Tag for absence, too. 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.

What the criteria can and can’t express

The rules engine’s boolean logic is deliberately simple:

Each criteria line is an AND. All lines must match.
Multiple values within a single criterion are OR. For typed-in criteria, separate values with a semicolon (;).
There is no OR across criteria lines, no nesting, and no parentheses.

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.

Where rules fail silently

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.

Diagnosing a rule that didn’t fire

In rough order of likelihood:

The order was multi-item and the rule keyed on SKU / item name / warehouse location. Start here. It’s the answer more often than anything else.
A rule above it has a blank criteria or action, killing everything below.
A rule below it overrode the result. Check the order activity log — the rule may have applied and then been undone.
The rule depends on a field set by a rule beneath it. Service before insurance, dimensions before Rate Shopper, tag before tag-criteria.
The order changed after import. Rules fired against the original data and never looked again.
The required field was empty at import. Usually weight, sometimes dimensions.

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.

Placing a decision you haven’t built yet

The list above is for a rule that already exists and isn’t working. This is the version for one you are about to write, and running it in order will keep a setup legible for longer than any amount of tidying afterwards.

Is this a fact about a product, about an order, or about a parcel in somebody’s hands? Those map to three different layers, and getting this wrong is the source of most rules that should not exist. A product fact goes on the product record or in a Preset Group. An order fact is a rule. A parcel that genuinely needs a person is a Shipping Preset.
What does it depend on that something else sets? Whatever that is has to have run already. Check it against the six constraints above before you decide where the rule goes.
What could overwrite it? Anything below it in the list, and anything in a later layer. If the answer is “a rule I wrote eight months ago”, find that rule now rather than after the invoice.
What reads it afterwards? A package applied without a name is invisible to a packer reading the packing slip. A service set after the account was chosen may not survive. A decision nothing downstream consumes is usually a decision that did not need automating.
Can you express it without a new rule at all? A tag on a product record, a value on a Preset Group, or a wider Rate Shopper service collection often removes the need for the rule entirely. The cheapest rule is the one you did not add, because every row costs comprehension for as long as the account exists.

If a decision survives all five, it is a rule and you know where it goes. If it fails the second or third repeatedly against the same other rule, the two are really one decision being taken twice.

A fair summary

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:

read what’s actually in a multi-item order
do math
see outside the order record
co-optimize two decisions against each other

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:

Simplify until the rules fit. Fewer box sizes, fewer services, more assumptive logic. Cheaper than it sounds, and often correct.
Accept the manual work. If it’s twenty orders a day, a person handling exceptions is fine and always will be.
Add logic above ShipStation that can read the full order, compute, call out for data, and write the decision back before your warehouse sees it.

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.

FAQ

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.