Published
ShipStation has a Product Preset Group and a Shipping Preset, and they solve opposite problems. A Preset Group applies shipping and customs values to a group of products automatically at import. A Shipping Preset is a saved bundle of shipment settings a packer applies with a keystroke or a barcode scan.
Both are useful and most accounts use neither properly. The naming is what causes it — people build one when they wanted the other, then conclude the automation does not work.
A Preset Group is a product default that applies to many products at once. ShipStation’s own framing: “a special kind of product default that includes shipping options and customs information, just like individual product defaults.”
You create them in the Preset Group section of the Products tab, then assign products to them either individually or by selecting a batch of products and clicking Add Preset Group.
What a Preset Group can hold, per ShipStation:
That last group is why Preset Groups matter more than they appear to. Customs data is the most tedious product data to maintain, and a Preset Group sets it for a whole category. If you have been filling in harmonization codes SKU by SKU, this is the layer you wanted.
They are overridden by individual Product Defaults, not replaced. ShipStation’s example is worth keeping: shirts are in a Preset Group at 8 oz on one service; a heavier XXL variant gets a Product Default of 10 oz; the order then uses the group’s service and the product’s weight. Adding a Preset Group does not overwrite anything already set on the product. Where a group value applies, the interface shows it italicised beneath the product default field, which is the only visual cue that a group is in play.
Preset Groups are product defaults, so they inherit the product-default restrictions, and those are tighter than most people assume.
From ShipStation’s Products overview: product defaults apply only when the order contains that product and nothing else, and the carrier, service, confirmation and dimension selections only apply when the item’s quantity is 1. Weight is the documented exception and applies regardless.
So on a two-item order, a Preset Group contributes weight and contributes nothing else. On a single-SKU order for three units, same answer.
That is not a small carve-out, and it follows from what a product default is: a statement about one product, which stops being well-defined the moment an order contains two. For most catalogues it means Preset Groups do the work on the single-unit tail and stop at exactly the orders that are hardest to configure. ShipStation’s own guidance points elsewhere for those: “Need to automate the shipping service for multi-item orders? You can do this using Service Mapping or Automation Rules.”
Which is the correct answer, and it is the single-line-item restriction showing up in a different part of the product wearing a different name.
A Shipping Preset is the other thing entirely. It is a saved bundle of shipment settings that a person applies at the shipment screen.
A preset can hold a ship-from location, shipping service, package type, confirmation, insurance, weight and dimensions — set as few or as many as you want. You create them from Apply Preset → Manage Presets in the Orders grid.
Two properties make them genuinely fast at a pack bench:
Hotkeys. Each preset can carry a keyboard shortcut, and it works on one order or a whole selection. As of August 2026 ShipStation caps this at 36 presets with hotkeys; you can create as many presets as you like beyond that, they just have to be picked from a menu.
Barcodes. Click Print Hotkeys and Barcodes and you get a sheet of your presets as scannable barcodes. A packer scans the sheet instead of typing, which is the difference between a shortcut and a workflow. This composes with the scan workflows rather than competing with them.
One configuration note that costs money if you miss it. If you have more than one account with the same carrier, sort the service list by account rather than by carrier when building the preset. ShipStation’s warning: if you sort by carrier, “the service you choose will always use the account designated as the primary carrier account.” A preset that silently routes to the wrong account is not something you will notice until the invoice.
From the same article:
You cannot currently use automation to apply presets.
That is the boundary, and it is narrower than it sounds, because the thing people want when they ask for it does exist under a different name.
A Shipping Strategy is a saved Rate Shopper configuration, and Set Shipping Strategy is a standard automation action in the criteria and actions reference — it applies the strategy and a package type to the matched order. So a rule can hand an order a saved service-selection policy plus a box, which is most of what a Shipping Preset holds and better than a preset in one respect: a strategy compares live rates rather than fixing one service in advance.
The rest of a preset’s contents are directly settable by rule anyway. Set Carrier/Service/Package, Request Confirmation, Insure the Package, Set Ship From Location, Set Package Dimensions and Set the Total Order Weight are all standard actions. Between a Shipping Strategy and those, there is very little a preset does that a rule cannot.
Which leaves Shipping Presets doing the job they are actually good at: the orders where a person has to look at the parcel and decide.
The question is not which is better. It is which layer the decision belongs in.
Use a Preset Group when the answer is a property of the product and it is the same every time. Category-level customs data, a standard box for a product line, a weight. It happens at import, before anyone touches the order, and it costs nothing at pack time.
Use an automation rule, or a Shipping Strategy applied by one, when the answer depends on the order — its value, destination, contents, tags, or what the customer picked at checkout — or when it needs to work on multi-item orders. This is most non-trivial routing, and it is where the single-line-item restriction stops applying.
Use a Shipping Preset when the decision genuinely requires a person. Oversize items, fragile handling, anything where somebody looks at the parcel and decides. A preset makes that decision one keystroke instead of five fields, and that is a real saving on the orders that need it.
The failure mode is using presets for the second category — building thirty presets that a packer has to choose between, which reintroduces the judgement call you were trying to remove and makes it slower.
ShipStation applies things in a fixed order at import: Auto-Split, then SmartFill, then Product Defaults and Preset Groups, then Service Mapping, then automation rules top to bottom. Later layers overwrite earlier ones.
Preset Groups are early in that chain, which means an automation rule beats them every time. If a Preset Group value is not showing up on your orders, a rule below it is the first place to look. The order of operations is the single most useful thing to hold in your head when something is not applying, and it explains almost every case of a setting that appears to be ignored.
Shipping Presets are not in that chain at all. They happen after everything, when a person applies them, and they overwrite whatever was there.
Open your Preset Groups and look at what is actually in them. Most accounts that have them use them for a service and a box and leave the four customs fields empty, which is the half with the most manual work attached.
Then count your Shipping Presets. If there are more than a handful and they encode order-dependent logic rather than product-dependent logic, some of them should be rules, and the ones that become rules stop needing a human at all.
Neither feature decides a box for an arbitrary basket of items. A Preset Group holds one set of dimensions for the products in it, which is right when those products ship in a standard carton and useless when the box depends on what else is in the order.
That is cartonization, it is a computation rather than a lookup, and no amount of preset configuration approaches 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.
