Skip to main content
Under Review

Split of 'package' from Action Type "Set Carrier/Service/Package"

Related products:Orders & Shipment Management
  • July 16, 2026
  • 5 replies
  • 19 views

Chad_Kinsworthy

The Action Type "Set Carrier/Service/Package" should be split into two distinct actions:

  • Set Carrier/Service
  • Set Package

This Action Type unnecessarily requires a specific carrier/service if you want to set a package type, this should be two separate actions. 

5 replies

  • Community Manager
  • July 16, 2026

Hi there, thank you for taking the time to share this feedback! I can definitely see how decoupling the package type from the carrier/service in automation rules would give you more flexibility. I am logging your specific use case with our Product team so they can track the demand for it!


  • Community Manager
  • July 29, 2026
Updated idea statusNewUnder Review

dashipper
  • Employee
  • August 11, 2026

Hi there, thank you for taking the time to share this feedback! I can definitely see how decoupling the package type from the carrier/service in automation rules would give you more flexibility. I am logging your specific use case with our Product team so they can track the demand for it!

In the meantime, a great workaround is assigning default package types directly to your Item Records. This way, the package type automatically populates when that specific product is ordered, completely independent of your carrier automation rules.

Hello!

Can clarify how you assign default package types directly to your item records? I have the exact same problem as the OG on this case, this is critical issue for any shipper that does not want to auto select the service level for the item (Many marketplace channels don’t support this). I have reviewed all pages of the items record on the Product Tab and am not finding a way to preselect the package type without also selecting the service level.


  • Community Manager
  • August 11, 2026

Hi there, thank you for taking the time to share this feedback! I can definitely see how decoupling the package type from the carrier/service in automation rules would give you more flexibility. I am logging your specific use case with our Product team so they can track the demand for it!

In the meantime, a great workaround is assigning default package types directly to your Item Records. This way, the package type automatically populates when that specific product is ordered, completely independent of your carrier automation rules

Hello!

Can clarify how you assign default package types directly to your item records? I have the exact same problem as the OG on this case, this is critical issue for any shipper that does not want to auto select the service level for the item (Many marketplace channels don’t support this). I have reviewed all pages of the items record on the Product Tab and am not finding a way to preselect the package type without also selecting the service level.

My apologizes. It is stuck behind a service selection even on the product level. I’ll see if we can get this changed. 


dashipper
  • Employee
  • August 12, 2026

Hi there, thank you for taking the time to share this feedback! I can definitely see how decoupling the package type from the carrier/service in automation rules would give you more flexibility. I am logging your specific use case with our Product team so they can track the demand for it!

In the meantime, a great workaround is assigning default package types directly to your Item Records. This way, the package type automatically populates when that specific product is ordered, completely independent of your carrier automation rules

Hello!

Can clarify how you assign default package types directly to your item records? I have the exact same problem as the OG on this case, this is critical issue for any shipper that does not want to auto select the service level for the item (Many marketplace channels don’t support this). I have reviewed all pages of the items record on the Product Tab and am not finding a way to preselect the package type without also selecting the service level.

My apologizes. It is stuck behind a service selection even on the product level. I’ll see if we can get this changed. 

Yes, this would be very helpful to decouple service from package type. In our case, we are almost always shipping with the same package type for most single QTY singly SKU orders. But, because we heavily rely on Amazon’s Shipping Settings Automation, we cannot preselect a service level based solely on a SKU id, we must use Amazon’s shipping recommendations in order to comply with their ODTR rules.

It doesn’t seem that ShipStation really supports Amazon’s Shipping Seller Automation fully, which is odd considering how many ShipStation customers probably heavily rely on Amazon as a sales channel.

Q. As a reasonable guess, do you know how long it would take your Product Team to decouple the package type/size from the service selection, either at the product level and/or as part of Automation Rules?

 


dashipper
  • Employee
  • August 12, 2026

Please send this information over to the Product Team for review. Thank you!

User Story

As a ShipStation user managing automation rules and product default shipping settings, I want to set my Package Type independently of my Carrier/Service, so that I can standardize packaging across orders or products without being forced to lock in a single carrier or service to do it.

Current Behavior

  • The automation rule action "Set Carrier/Service/Package" requires a Carrier/Service and a Package Type to be selected together in a single action, you cannot set one without the other.
  • The same limitation exists at the product level: default shipping settings on a product require both Carrier/Service and Package Type together. There's no way to default just the package type and leave carrier/service open.

Desired Behavior

Split the single combined action/setting into two independent ones:

  1. Set Carrier/Service: sets/defaults the carrier and service only.
  2. Set Package: sets/defaults the package type only.

Either should be usable on its own, or both together, in the same rule or product setting. Neither should require the other to be present.

Why This Matters

  1. Rate shopping across carriers breaks otherwise. Shippers who compare rates across multiple carriers/services per shipment (to get the cheapest or fastest option) but always want the same package type for a given item currently have to create a separate rule for every carrier/service just to lock in one package type. One rule intent becomes many rules.
  2. Combinatorial rule/setting explosion. With multiple package types and multiple carriers in play, you end up needing a rule (or product setting) for every package type × carrier combination, instead of one rule per package type. Every carrier change, rate change, or new service added means hunting down and updating every affected rule, a maintenance burden and a source of inconsistency.
  3. Package type is stable; carrier/service is volatile. Package type is a physical attribute of the product, it doesn't change often. Carrier/service selection is a cost- and speed-driven decision that shifts with negotiated rates, zones, weight breaks, or business priorities and can change frequently. Bundling a stable setting to a volatile one means unrelated changes force unnecessary edits elsewhere.
  4. Separation of concerns. Packaging and carrier selection are managed by different logic (and sometimes different people/processes) in most shipping operations. Forcing them into a single action doesn't reflect how shippers actually make these decisions.

Where This Applies

  • Automation Rules → Action Type → "Set Carrier/Service/Package"
  • Product Settings → Default shipping settings (Carrier/Service + Package Type)

Impact of the Change

  • Cuts the number of required automation rules/product settings from (package types × carriers) down to just what's needed for each independent decision.
  • Removes redundant rule maintenance when carrier rates or service options change.
  • Makes automation rules and product defaults match how shippers actually think about packaging (fixed) vs. carrier selection (variable).