String
Automation rules

How to Hold Orders and Flag Exceptions in ShipStation

Published

Yes, and this is the part of the rules engine people underuse most. Not every decision has to be made by the automation. Some of them only have to be routed to whoever should make them.

The actions

From ShipStation’s criteria and actions reference, the ones that park work rather than complete it:

  • Hold Until — moves the order into On Hold until a date you set, then releases it to Awaiting Shipment automatically
  • Create an Alert — a message on the order, with an expiry you set
  • Add an Internal Note — quieter than an alert, and it persists
  • Add a Tag — the classification other rules and filters key on
  • Assign to a user — puts the order in a named person’s queue
  • Set Custom Field 1/2/3 — somewhere to record why

Alongside those, rules can add insurance, request confirmation, and flag dry ice with a declared weight.

The pre-order pattern

The most common use of Hold Until is a pre-order. ShipStation’s own worked example sets the criteria to an order tag and adds a Hold Until action with the release date. The orders leave the queue and come back on their own when the date arrives.

A fixed date in a rule goes stale

That worked example, and the rest of ShipStation’s documentation, describes Hold Until as a calendar date. For a one-off hold applied to a batch of orders by hand, a date is exactly right.

Inside an automation rule it ages badly. The rule holds every matching order until the same fixed day, so the moment that day passes the rule is holding orders until a date in the past, which holds nothing. It does not error and it does not warn. It quietly stops doing the thing you built it for, and the first sign is usually a pre-order shipping early.

In the accounts I work in the action now also takes a number of days rather than a date, and offers an indefinite hold. Neither is in ShipStation’s documentation, so check what your own account offers before planning around it.

Both are worth knowing about, because they fix different halves of that problem:

  • A number of days is relative to the order, so the rule stays correct without anyone revisiting it. “Hold for 14 days” means the same thing in March and in November. If you are writing a hold into a rule rather than applying one by hand, this is almost always the one you want.
  • An indefinite hold is for the case where no date is the answer — the order waits for a person to decide something. It pairs with the tag-and-alert pattern below, and on accounts that have the newer workflow triggers, with a tag being removed as the signal to release it.

Worth noting the criteria choice in that example. ShipStation uses order tags rather than Item SKU, because SKU criteria only evaluate single-line-item orders and a pre-order that arrives with anything else in the basket would slip past a SKU rule. Tag the product record instead and the tag lands on any order containing it.

Tag and alert, on purpose

The pattern worth internalising is the one for decisions the engine genuinely cannot make: identify the order, flag it, hand it to a person.

A rule that says “if the order contains a hazmat SKU and the destination is international, tag it, alert it, and assign it to the compliance queue” has not automated the decision. It has made sure the decision reaches the right desk on the day the order lands, rather than at the packing bench three days later.

That is a legitimate outcome, not a workaround. The alternative to a person deciding is not usually a rule deciding correctly. It is a rule deciding wrongly and nobody noticing.

Where it stops

Two limits worth knowing.

A hold waits, it does not watch. A date, a number of days, or indefinitely — none of them is a condition. There is no action that says “hold this until something becomes true”, so anything conditional needs a person, or a second rule on a different trigger, to release it.

Rules fire once. Classic automation rules run when the order first lands, and changes after that do not re-trigger them. An order held on Monday is not re-evaluated on Wednesday unless someone reprocesses it, or unless your account has the newer workflow triggers, where a tag being removed can start a chain.



When the rule can't express it

Eight situations where the decision depends on something an automation rule cannot see.

See the eight situations