Published
Short answer: there are three kinds of tag in ShipStation and they land at three different moments. Product tags and customer tags are applied to the order at import, before any other automation applies; rule-applied tags are added part-way through the rule list and are only visible below the rule that added them.
That timing is the whole reason tags matter. A product tag is on the order before Preset Groups, Product Defaults, Service Mapping and every automation rule run, which is why it works on a multi-item order when an Item SKU criterion does not.
Product tags. Tag a product record and ShipStation applies that tag to any order containing that product when it imports. Applied on the Products tab: select the products, click Tag, pick the tags. ShipStation’s own examples of what these are for are fragile products, products that ship with dry ice, pre-order products and products that get drop-shipped.
Customer tags. Same mechanism on the Customers tab. Tag a customer record and future orders from that customer arrive carrying the tag. ShipStation names two standard uses — loyalty and fraud risk — and gives worked rules for both: a frequent-buyer tag that raises an alert and sets an expedited service, and a fraud-risk tag that moves the order to On Hold, raises an alert, and assigns it to a supervisor.
One thing to know before you build much on customer tags: ShipStation states each customer record is marketplace-specific and based on username, so a person who buys from you on two channels is two customer records, and you may need to combine them for the tag to follow both.
Rule-applied tags. The Add a Tag action. These land mid-list, and the constraint is positional — a tag applied by a rule is only available as criteria to rules below it. That is what makes a classification pass possible, and it is covered properly in how the rules engine actually behaves.
By hand. From Order Details via Edit Tags, or from the Orders grid with several orders selected at once, which is the fast route. Tags are created and renamed through Manage Tags in the same menu, each with a name and a colour. Minor quirk worth knowing because it looks like a bug: ShipStation states you cannot create a new tag while you are editing an existing one — finish the edit first.
This is the mechanism, and it is more specific than “tags are a workaround.”
Item SKU, Item Name and Warehouse Location criteria only evaluate orders containing a single unique line item. Add anything else to the basket and the rule skips the order without saying so.
Product tags are not subject to that, and the reason is that they are not a rule criterion being evaluated against line items. They are a product default field, written onto the order at import. ShipStation states the boundary precisely in its multi-product orders article: “For multi-product orders, however, the only Product Defaults that will apply are Weight, Order Tags, and Customs Declarations.”
Three fields survive a mixed basket. Tags are one of them. Everything else on the product record — service, package, dimensions — needs a single line item to apply.
So by the time your rules evaluate, an order is already labelled with the attributes of everything in it, however many items it holds. You are no longer asking a question about line items. You are asking a question about the order.
The useful discipline is to tag categories, not conclusions.
ShipStation’s own worked example is a clothing store selling shirts, pants, hats and shoes, with one tag per product type. Note what those tags are: they describe what the product is, not what should happen to it. The shipping decisions are then expressed as rules reading combinations of those tags.
Tag FRAGILE, not USE_BOX_C. The first stays true when your packaging changes; the second is a decision frozen into a product record, and it has to be re-entered across the catalogue the day you switch boxes.
Categories worth a tag in most operations:
Then the pattern that makes it work: a classification pass above an action pass. Early rules decide what an order is and tag it; later rules read those tags and act. That structure is what keeps a large rule set legible, and it is the same shape as routing exceptions to a person — classify at import, act afterwards.
ShipStation’s multi-product article gives five, and between them they cover most of what a tag set needs to express. The mechanic underneath is one documented rule: multiple tags on a single criteria line mean ANY of them; one tag per criteria line means ALL of them.
Order Tags :: Include :: SHOES — fires on any order containing a shoe, whatever else is in it.Do Not Include line listing every other category tag. ShipStation’s example is an order containing only hats, shipping in a thick envelope.Do Not Include line added.Shape 2 is the one people miss and it is the one that makes a category system work, because “only hats” is not expressible without naming the absence of everything else. Which is also the argument for keeping your category tags to a number a person can hold in their head — every extra category lengthens every Do Not Include line you write.
If you are building several similar rules, ShipStation notes a Copy action on a saved rule, which is faster than rebuilding the criteria each time.
The most valuable list in a tagged account is the one that finds the gap rather than the known set: orders that came out of the classification pass with nothing on them. Those are the orders no handling rule touched, and nothing downstream is looking for them.
ShipStation states that you can filter orders by tag to view “orders excluding specified tags”. What it does not say is where, and this is worth spelling out because the obvious place is the wrong one.
The exclusion is not on the filter bar. The tag filter on the Orders grid selects tags to include. In the accounts I work in there is no negative operator there, and looking for one is how most people conclude the feature does not exist.
It lives in the Order Filter builder, under Account Settings → Automation → Order Filters. That dialog is a different control with an operator dropdown, and the operators on Order Tags include Do not Include. The value picker is a multi-select list of your tags, and the dialog states its own boolean: the filter matches any order matching ALL of the criteria lines you add.
So the negative is built once, saved as a named filter, and then used somewhere else. A saved filter appears in the Saved Filters menu on the Orders tab, so you can pull it into a view — and it is also available to the rules engine through the Orders match an existing filter criterion. Build it once, use it in both places.
That is the whole trick, and it is the clearest illustration of a distinction worth internalising: a saved filter is reusable logic and a saved view is a way of looking. The filter bar is deliberately simple. The filter builder is where the boolean lives.
One caution on the multi-select. For rule criteria ShipStation documents the semantics plainly — several tags on a single line means any one of them, and one tag per line means all of them. It does not document the same thing for filters. If you are building “carries none of my category tags,” give each tag its own criteria line rather than selecting them all on one, which is unambiguous under either reading. Selecting five tags on a single Do not Include line may well mean “missing any one of these,” which matches almost every order in the account.
A filter is a live query. Sometimes you want the absence recorded on the order instead, and that is a rule at the end of the classification pass — one Order Tags :: Do Not Include line per category tag, with an Add a Tag :: UNCLASSIFIED action.
The trade is durability against freshness. A tag is a record of what was true at import, so it survives into reports and downstream rules and can be read by anyone. It also goes stale: classic rules fire once, so an order tagged UNCLASSIFIED on Monday keeps the tag after you fix the product record, and clearing it is a manual action on the grid. The saved filter has the opposite properties — always current, never recorded anywhere.
Use the filter to watch, and the tag when something downstream has to act on it. Either way this is the list worth opening weekly. It is the closest thing to a test suite the rules engine has.
Tags are cheap to create and expensive to keep true. Four documented behaviours decide how much that costs you.
A new SKU with no tags falls through every rule keyed to them. Silently. No error, no unmatched-order queue, just an order that none of your handling rules touched. This is the failure mode of the whole approach and it arrives with every catalogue addition.
The product CSV is how you keep up. Product records import and update by CSV with Tags and Tag1 through Tag5 columns, and the same upload carries weight, dimensions and customs details. ShipStation notes you can include the tag in the import file rather than tagging in the interface afterwards, which is the difference between a maintainable system and an afternoon every month.
Tags can be added by CSV but not removed by it. ShipStation states this directly. Removal is an interface action on the Products tab. So a CSV round-trip will not clean up a tag you have retired.
The CSV tag field has a 29-character limit, and ShipStation is explicit about what happens past it: “The tag will not add if it has 30 characters or more.” It does not error. Keep tag names short, and check a sample after any bulk import.
One more, and it catches people out because it seems like it should work the other way: removing a tag from a product or customer record has no effect on orders that already imported. It only stops future orders being tagged. A tagging mistake is never retroactively fixed; those orders need correcting on the Orders grid.
Worth stating plainly, because the limit is structural rather than a setting.
A tag answers a yes/no question — is this thing in the order. It carries no quantity, no per-item dimensions and no relationship between items, so an order tagged FRAGILE might hold one wine glass or nine. That is set membership rather than the bill of materials, and it is where tag-based classification stops.
None of this is ShipStation being deficient. A flat, colour-coded label that any rule can read is a deliberately simple primitive, and simplicity is why it works everywhere in the product at once — on the grid, in filters, in saved views, as rule criteria, and on the product and customer records.
Two smaller limits worth knowing. ShipStation documents no limit on the number of tags you can add to an order, so the constraint is comprehension rather than the platform. And on split shipments, ShipStation states that each shipment can carry its own set of tags and that split shipments do not inherit the tags from the original shipment — so a tag applied at import is not automatically on the pieces a split creates.
Write down your categories before you create any tags. Five to ten, describing what a product is. If a proposed tag names an action rather than an attribute, it belongs in a rule.
Tag the product records, not the orders. That is the layer that reaches multi-item orders, and it is the one that keeps working as your rule set changes.
Do it in the CSV. Tags, weight and dimensions in one upload, with names under 29 characters.
Add a saved view for untagged orders, and look at it weekly. It tells you whether the system is still true, which nothing else in the account will.
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.