Published
Most people call these folders. ShipStation calls them saved views, and you make one by filtering the Orders grid and clicking Save — no folder, no drag and drop, and nothing gets moved anywhere.
That naming difference is the whole reason this page is hard to find. Below is how to build one, which criteria are worth putting in a review queue, and the one thing a saved view will not do for you.
Two different features, with confusingly similar names, doing different jobs. Getting them straight first saves an afternoon.
A saved view is a tab on the Orders grid. ShipStation defines it as “a saved collection of filters, columns, and column sequences” — so it holds not just which orders you see but which columns and in what order. It is for looking at things.
A saved filter is reusable logic, built somewhere else entirely: Account Settings → Automation → Order Filters. It shows up in the Saved Filters menu on the Orders tab, and it can also be used as automation rule criteria through the Orders match an existing filter criterion. It is for defining a set of orders once and using it in more than one place.
Neither is a folder in the sense the word implies. Nothing moves. An order in your review queue is also still in Awaiting Shipment, still in whatever other views match it, and still exactly where it was. A view is a question you saved, not a container.
That distinction turns out to be the useful half. An order can be in six views at once, and a view updates itself the moment an order changes.
The whole procedure, from ShipStation’s documentation:
Two things about that sequence are worth noticing. The count appears before you save, so you can see whether your filter is any good while you are still building it — a review queue returning 400 orders is not a review queue. And the columns are part of the view, which is the part most people skip. A queue for address problems should show the address columns and not the rate columns, and ShipStation saves column changes per view automatically once you are inside one.
How many you get depends on your layout, not your plan. The new layout allows an unlimited number of saved views. ShipStation Legacy caps them at five, and in Legacy they exist only on the Orders tab — the Shipments tab has no custom views in Legacy at all.
Editing has a quirk. Renaming and deleting are done by hovering the view’s title and clicking the pencil icon. But adding or removing a filter inside a view does not amend it: ShipStation states that this “will add this as a new View.” So a view you keep tweaking will spawn siblings. On the Shipments side there is an explicit Overwrite an existing saved view option in the save dialog; if you want that behaviour on Orders, save and then delete the old one.
Pinning is capped at two. In the Manage Columns pop-up you can pin columns so they stay put when the grid scrolls sideways, and ShipStation allows a maximum of two. Order # and Age is usually the right pair for a queue you actually work.
The filter list is long. These are the ones that earn a place in a queue of orders somebody has to look at, rather than a queue somebody has to ship.
Age. The single most useful field for this, and it is a column rather than a filter. ShipStation documents Age as the current time minus the order time for anything in Awaiting Shipment, shown in hours up to 72 and in days after that, and it sorts. Sort descending and the oldest thing in your operation is the first row. If you only ever do one thing from this page, do that.
Tags. The backbone of a review queue, and the subject of the next section.
Destination and Country. ShipStation’s international example uses the Destination filter for the domestic/international split and the Country filter for named countries. Customs review is usually a country list rather than a blanket international rule.
Order Date and Created Date. For the orders that arrived before a cutoff and are still here.
Assigned To. If exceptions get routed to named people, this is how each person opens their own list.
Insurance, Customs Forms, Label Created, Packing Slip Printed. All documented filters, and all useful negatively — the queue you want is usually orders where one of these has not happened yet.
Item SKU, with a caveat that runs the other way from the one you expect. ShipStation documents this directly and it is the single most surprising line in the filter documentation: “Item SKU as a filtering criterion applies to both orders containing just the Item SKU and orders containing the Item SKU and other line items. However, when you use Item SKU as an Automation Rule criterion, the rule will only apply to orders containing a single line item.”
So the grid can find a SKU inside a mixed basket and the rules engine cannot. If you have been working around the single-line-item restriction, note that the workaround is only needed on the automation side. A saved view finds those orders fine.
One limit on all of them: filter fields have a documented character limit of 2,000, so a filter listing several hundred SKUs will hit a wall.
Worth also knowing Group By, which is not a filter and often does the job you were about to build a view for. It groups Awaiting Shipment orders by Store, # Line Items, Total Quantity, Country, Item Name, Item SKU or Requested Service, and you can combine two. For “show me what is here, arranged usefully” it beats building four views.
This is the part that decides whether your review queue works.
A filter reads what is already there. Country, weight, order total, service, age — facts that arrived with the order or were set by an earlier layer. A filter asks a question about the order record.
A tag is something you put there. It arrives from a product record, a customer record, or an automation rule, and ShipStation applies product and customer tags at import before any automation runs. A tag records a judgement that has already been made.
That difference tells you which to use. If the grid can express the condition, filter on it and skip the tag — a view for international orders needs no INTERNATIONAL tag, because Destination is right there. If the condition takes reasoning the filter bar cannot do, make a rule decide it at import and have the rule apply a tag, then filter the tag.
That second pattern is the whole relationship between this page and the alerts a ShipStation operation should set up. The rules do the classifying at the moment the order lands. The view is what you open afterwards to work the results. An address that failed validation, an order that has to be split before anyone can fulfil it, a product flagged for special handling — each of those is a rule that tags, and one saved view filtering on those tags is the queue.
Two details matter when you build it that way.
The queue you usually want is a negative one — everything not yet reviewed — and that is the clearest case for a saved filter over the filter bar. The tag filter on the grid selects tags to include. The Order Filter builder, under Account Settings → Automation → Order Filters, offers Order Tags with a Do not Include operator, and the dialog states that a filter matches orders meeting ALL of its criteria lines. Build the negative there, save it, and it appears in the Saved Filters menu ready to pull into a view. That is exactly the division of labour described above: the view is how you look, the filter is what you asked for.
Tags applied to a product or customer record do not reach orders that already imported; removing one only stops future orders being tagged.
Saved views are shared by default. ShipStation states it plainly for both grids: they “are available to all users in your ShipStation account.” There is no per-user or private view, and nothing to switch on. Build a good queue and everyone has it.
What differs between users is not the view but what is inside it. User restrictions include Restrict this user to only see orders assigned to them, which limits that person’s viewing and modification to their assigned orders. Combine that with the Assign to a user rule action and one shared saved view shows each person only their own exceptions, without anybody maintaining a view per person. That is a genuinely tidy arrangement and almost nobody uses it.
Saved filters are shared the same way — ShipStation says filters saved through Order Filters are “available to all users on the account.”
The one thing that is per-user is dismissal of alerts, which is the opposite of how the views behave and catches people out. An alert somebody cleared is still waiting for everyone else; a view somebody built is immediately everyone’s.
It shows you orders. It does not act on them.
There is no action attached to a view, no notification when something enters one, and nothing that fires when the count goes up. A view is a place you go. If the condition needs to come and find someone, that is an alert or an email from an automation rule, and it is a different mechanism entirely. Building the view is not a substitute for building the rule, and an operation that relies on a queue nobody opens has automated nothing.
The exception, and it is a real one, is the saved filter. Because Orders match an existing filter is an automation rule criterion, a set of orders you defined once on the grid can drive rule actions. That is the closest thing to a folder that does something, and it is worth knowing about.
It comes with a documented catch. ShipStation states that when a filter is used as rule criteria, the orders “must also meet the general requirements if the criteria were being used without the filter settings” — so a filter keyed on SKU, Item Name or Warehouse Location will only apply the rule to single-item orders. The restriction the grid does not have comes back the moment the filter is used to act. The saved filter does not launder it.
None of this is ShipStation being deficient. A grid that filters, sorts and groups against every field on the order is a well-built piece of software, and the reason it does not act is that acting is what the rules engine is for. The two halves are deliberately separate.
Three views, and they take about twenty minutes.
Everything sorted by Age, descending. No filters at all. Pin Order # and Age. This is the view that tells you whether anything is quietly rotting, and it is the one most operations do not have.
One queue per exception you actually route. Filter on the tags your rules apply and add the columns relevant to that exception. Address problems get the address columns.
One negative view. Orders where something has not happened — no label yet, no customs form, no classification tag. Build the tag exclusion as a saved filter and pull it into the view. The absence queue catches the orders that fell through every rule you wrote, which is the category nothing else in the account is looking for.
Then decide who opens which, and at what time of day. A saved view is a piece of workflow, and it only works if somebody is on the other end of it.
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.
