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.
From ShipStation’s criteria and actions reference, the ones that park work rather than complete it:
Alongside those, rules can add insurance, request confirmation, and flag dry ice with a declared weight.
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.
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:
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.
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.
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.
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.