Published
Short answer: “exception notice” means two different things in ShipStation and they have different answers. If you mean the message a customer gets when a parcel goes into a delivery exception, ShipStation tracks that status and sends no email about it — what ShipStation tells your customer covers the customer-facing side in full and this page does not repeat it.
If you mean the internal notice that puts an order in front of a person before it ships, that is an automation rule with two actions on it. This page is the list of conditions worth building one for, the criterion each one needs, and the three conditions you cannot detect at all.
Every alert below is really two things, and operations use both because they reach different people at different moments.
A tag is something you put on the order. Add a Tag applies a colour-coded label the grid displays in its own column, sorts on, and filters on — including filtering for orders that exclude a tag. A tag is passive. Nobody is told. It is there for whoever opens the queue.
An alert is something somebody sees. Create an Alert writes a message into the numbered alert list next to the profile icon in ShipStation. You set the text and how long it lives, and the text can carry four field replacements — Store Name, Recipient Name, Order Date and Order # — with the Order # rendering as a link straight to the order. Automation rule alerts sit alongside three native types ShipStation raises on its own: combine order alerts, new product records, and low inventory.
Two things about alerts are worth knowing before you rely on them. Dismissing one dismisses it for that user only, so an alert somebody cleared is still waiting for everybody else. And they live inside ShipStation, so they reach whoever is already looking at ShipStation.
An email leaves the building. Send an email sends to an address you name, or to the customer or store address, when the rule runs. Three constraints are documented: it fires immediately at import rather than at label creation, it applies to an order only once and does not re-fire on a rules reprocess, and it is disabled on trial accounts until support enables it. ShipStation’s own worked example also notes the rule needs an email template created in your template settings first.
Assigning is a queue, not a notice. Assign to a user puts the order in a named person’s name, and the Orders grid has an Assigned To filter for it. Nothing is sent. It is the right action when the exception belongs to one desk and that desk works a list.
So the shape of a good alert rule is: one criterion, Add a Tag, and one of Create an Alert or Send an email depending on whether the person needing to know is in ShipStation already.
Start here. It is the one nearly every account should have, and it is the clearest example of the shape.
ShipStation runs address validation on every order shipping to or within a supported country, and exposes the result to the rules engine as the Address Verified criterion, with values of Verified, Warning or Error.
Then it stops. ShipStation states it for both failure classes, in the same words: a verification warning “will not prevent you from attempting to create a label,” and an address verification error “will not prevent you from attempting to create a label.” If the postage provider later finds fault, it rejects the label and you fix the address then. Nothing in ShipStation blocks the attempt.
So an order with a bad address sits in Awaiting Shipment looking exactly like every other order, and ships, unless somebody looks. The platform has the finding and does not act on it. That is the gap the alert fills.
Build it as two rules. ShipStation documents that Address Verified cannot take more than one value in a single criteria line — “if you want automation to apply when an address is verified as a Warning or an Error, you must have two automation rules, one for each value.” That is a better design anyway, because the two are different failures. An error usually means a wrong address and belongs to whoever contacts customers. A warning usually means a unit number that could not be confirmed, and often ships fine. What the validation statuses actually mean goes into which of them deserve which response, and how the answer changes on international lanes.
Address Verified equals Error. Second rule: Address Verified equals Warning.Add a Tag (ADDRESS ERROR / ADDRESS WARNING), Create an Alert on the error rule.It will still take a label, at whatever weight somebody types at the bench or whatever the carrier decides afterwards.
Order Weight is a rule criterion and takes numeric comparisons, so the rule is a floor: order weight is less than the lightest thing you actually ship. Set the number below your smallest real parcel and above zero, and the rule catches the orders that arrived without one.
Put this rule after the layers that legitimately supply a weight. Weight arrives from five places and SmartFill, Preset Groups and Product Defaults all run before automation rules, so by the time your rule evaluates, the only orders still under the floor are the ones none of those layers could supply a weight for. Those are exactly the ones worth a tag.
One documented caveat, and it is a real one: rules using Order Weight, Order Total, Order Subtotal or Total Quantity do not run on Shopify orders that import into the On Hold status, because Shopify sets the quantity to 0 until the status changes. If you sell on Shopify and hold orders, this rule has a blind spot and it is the platform’s, not yours.
What ShipStation does not document is how a completely absent weight evaluates against a numeric comparison, as against a weight of zero. Test the rule on a real order from the channel you care about before you trust it.
Order Weight is less than [your floor].Add a Tag (NO WEIGHT), Create an Alert.The straightforward one, and the one with money attached.
Order Total, Order Subtotal and Amount Paid are all criteria and all take a greater-than comparison. Above your threshold you probably want three things at once: the insurance, the tag, and somebody’s eyes.
Insure the Package is a rule action and it fires on any criteria the engine can read. Watch the sequencing if you use carrier insurance rather than a third-party provider: ShipStation’s own documented example is that a rule adding carrier-specific insurance fails when no earlier rule has set the service, so the insurance rule goes below the service rule in the list.
The same Shopify On Hold caveat above applies to Order Total and Order Subtotal.
Order Total is greater than [threshold].Insure the Package, Add a Tag (HIGH VALUE), Create an Alert.Do not build this on Item SKU. SKU, Item Name and Warehouse Location criteria only evaluate orders with a single unique line item, and the multi-item orders are usually the complicated ones.
Tag the product record instead. ShipStation applies a product’s tags to any order containing it at import, before any automation runs, so Order Tags :: Include works on an order of any size. ShipStation’s own examples of what product tags are for are exactly this list: fragile products, products that ship with dry ice, pre-order products, and products that get drop-shipped.
Customer tags work the same way and are worth setting up alongside. ShipStation names the two common uses directly — VIP customers, and customers with a history of fraudulent orders, where the documented rule adds an internal note and an alert.
One maintenance fact worth knowing before you build a lot of this: removing a tag from a product or customer record has no effect on orders that already imported. It only stops future ones being tagged.
Order Tags :: Include :: FRAGILE.Add an Internal Note, Create an Alert, or Assign to a user if one desk owns it.If part of an order goes to a fulfilment provider and part ships from your own shelf, nobody can act on it until it is split, and there is nothing on the grid that says so.
ShipStation documents the rule for this and it is a good one. Tag your products by fulfilment method, then write a rule with two separate Order Tags :: Include lines — one for the externally fulfilled tag, one for the self-fulfilled tag — and give it Add a Tag (SPLIT ORDER) plus Create an Alert. Two lines rather than one matters: ShipStation explains that multiple tags on a single criteria line mean any, and one tag per line means all, which is what you want here.
The boundary is worth stating plainly, because it is easy to expect more. This alerts you that an order needs splitting. Nothing alerts you that one was split, and there is a documented reason the obvious workaround fails: split shipments do not inherit the tags from the original shipment. Splitting is three different features that get conflated, and none of them raises a notice.
International Order is a criterion, and so is Country. ShipStation’s own worked example is a rule that tags every order without a domestic destination, with a variant that tags per country.
One piece of behaviour to know: when you build a rule for domestic shipments, ShipStation automatically sets the criteria field to International Order = False. So the domestic and international halves of your rule set are already separated for you.
Most international orders do not need a human. The ones that do are usually a specific commodity, a specific destination, or a value over a threshold, so this rule is normally International Order equals True and something else. Automating the declaration itself is a separate job with six rule actions of its own; this one is only about routing the exceptions to a desk.
International Order equals True, Order Tags :: Include :: RESTRICTED.Add a Tag, Assign to a user, Create an Alert.This is ShipStation’s documented fraud example and it earns its place, partly because it uses a capability that exists nowhere else in the engine: Recipient Name is the only criterion that supports a field replacement as its value, so you can compare it to the buyer name rather than to a string you typed.
ShipStation is careful about what the rule means, and the care is correct. A mismatch is frequently a gift order. The documented actions are a tag and an alert, and the article says explicitly that something more drastic like Don't Import the Order would not be appropriate here. ShipStation also states its own limits in this area directly: it does not handle checkout, it receives only part of the order information, and for most channels it imports no billing information beyond the buyer’s name. Fraud prevention belongs on the selling channel. This rule is a second look, not a control.
Recipient Name does not equal [Buyer Name].Add a Tag (REVIEW), Create an Alert.Total Quantity and # of Line Items are both criteria, and both are order-level, so neither has the single-line-item restriction.
ShipStation’s worked example is two rules: the first tags any order with more than three items, the second keys on that tag and sends an email to the warehouse manager so they can review the order before it ships. That two-rule structure is there for a reason — a tag applied by a rule is only visible to rules below it in the list — and it is also the cleanest illustration of the whole pattern on this page. One rule decides what the order is. The other decides who finds out.
This is the alert most likely to be worth setting on your own numbers rather than ShipStation’s. Three items is their example. Yours is whatever quantity your pick path stops handling gracefully.
Total Quantity is greater than [your number]. Second rule: Order Tags :: Include :: LARGE ORDER.Add a Tag, then Send an email on the second rule.This one is not an automation rule at all, and that is the thing worth knowing about it.
Stock level is not among the rule criteria, so no rule can test it. ShipStation handles low stock through a separate mechanism: a reorder threshold, set account-wide under Inventory Settings or per SKU on the product record, where the SKU-specific value overrides the account default. Below the threshold, ShipStation raises a Low Inventory Alert in the same alert list as your rule alerts, and shows a warning icon in the Alerts column of the Products Inventory grid — orange at or below your threshold, red at zero — with an Alerts filter to narrow the grid to just those, and a Low Stock report.
There is a second, harder interlock in the same settings page and most accounts have never opened it. For a product with no on-hand stock or an unknown stock level, Inventory Settings lets you choose whether ShipStation allows the shipment, allows it with a warning, or blocks it — and blocking prevents label creation for an order containing the out-of-stock item. That is the only place in this article where ShipStation will stop a label rather than mention something. It is worth a deliberate decision.
What none of it settles is which order gets the last units, which is a different question with a different answer.
Worth knowing before you spend an afternoon looking for the setting.
Package dimensions. The criteria and actions reference lists Set Package Dimensions as an action and lists no dimensions among the criteria. The engine can write a box onto an order and cannot read the one that is there. So “alert me when a multi-item order has no dimensions” is not expressible, however reasonable it sounds. Package is a criterion, but it is the package type selected, which is a different fact.
A shipping service that got cleared. Charge Shipping to My Account clears the order’s service when the selected account does not offer it, which ShipStation states plainly. There is no criterion for the service currently on the order, so no rule can notice the clearing and no alert can be raised on it. The answer is placement rather than detection: where that rule sits in the list decides whether it happens at all.
How long an order has been sitting. Start with the classic answer, because it is only half of one now. Automation rules run when an order first lands in Awaiting Shipment or On Hold, and changes after that do not re-trigger them. Elapsed time is a change after that.
That half has moved. On accounts with the redesigned Automation Rules screen, a workflow can run on a schedule rather than only at import, so a set of rules can look at the queue later in the day rather than only at the moment an order landed. I have seen this on a handful of accounts, none of it is documented, and it appears to be rolling out gradually — check Settings → Automation → Automation Rules in your own account rather than assuming from this page.
What a schedule does not change is the vocabulary. The criteria reference has Order Date and Ship By Date and nothing that expresses age, so a scheduled pass keys on a date rather than on how long an order has been waiting — and a fixed date written into a rule goes stale, in the same way a fixed Hold Until date does. When a workflow runs and what its rules can say are two separate limits, and this one is the second.
None of this is ShipStation being deficient. A rules engine that compares fields on the order record against values you typed in advance is a coherent and well-built thing, and all three of these are properties of that vocabulary rather than oversights.
All three are still visible — just as something you look at rather than something that finds you. ShipStation documents the Age column as current time minus order time for anything in Awaiting Shipment, displayed in hours up to 72 and in days after that, and sortable. The Orders grid has a Service filter. Both belong in a saved view somebody opens every morning, which is the subject of its own page.
Three rules, in this order, and they take about an hour.
The two address validation rules. They apply to nearly every account, the criterion is already populated on every order, and the failure they catch costs a reship.
One product-tag rule for whatever your operation gets wrong most often. Tag the product records first, since tags land at import before automation runs and work on multi-item orders. Then one rule reading the tag.
A reorder threshold, and a decision about the block setting. Both are settings rather than rules, and neither takes five minutes.
Then look at what you have built. The set of alerts an operation runs is a fairly precise description of where its automation stopped — every one of them is a decision the rules engine could identify and could not make. That list is worth reading occasionally as the operational document it is. And a decision routed to the right desk on the day the order lands is a legitimate outcome rather than a workaround. The alternative to a person deciding is rarely a rule deciding correctly.
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.