Most stores have at least one collection that’s off-limits to discounts. New arrivals. A collab with someone whose contract says no markdowns. A brand with MAP pricing that will pull your account if their products show up 20% off. Gift cards, obviously.
Shopify half-supports this, and the half it doesn’t support is where merchants get burned. Let’s take it from the top.
The native route, and where it runs out
When you create a product discount in Shopify, you choose what it applies to — specific collections or specific products. So for a simple case you can build the exclusion by inversion: instead of “everything except New Arrivals,” target the discount at the collections that are eligible.
That works until it doesn’t:
- Order discounts can’t do it at all. A 15% order-level code applies to the whole order, protected collection included. There’s no exclusion field.
- It only governs that one discount. Every future discount needs the same careful setup, done by whoever creates it, forever. One rushed Black Friday code and the collab is on sale.
- Other apps’ codes don’t care. Referral apps, loyalty apps, email tools minting unique codes — their discounts follow their own settings, not yours.
The pattern is the same one that shows up everywhere in Shopify discounting: native tools configure individual discounts, but nothing enforces a store-wide policy. “This collection is never discounted” is a policy.
Two ways to enforce it, depending on what you mean
“Exclude a collection from discounts” turns out to mean two different things, and they need different tools.
Meaning 1: codes work, but that collection isn’t discounted
The customer applies SAVE20, the code goes through, everything gets 20% off — except the protected collection, which stays at full price.
In PromoLock this is a cart group with an exclusion. When you build a discount, create a group that leaves the include list empty (that means the whole catalog) and puts your protected collection under Exclude. Aim the discount at that group. The excluded lines simply never receive it, quietly, on every offer you build this way.
This is the right shape for new arrivals and premium lines: the customer keeps their discount experience, your protected products keep their price.
Meaning 2: codes shouldn’t work at all when that collection is in the cart
Sometimes the policy is stricter — for a MAP-protected brand, maybe you don’t want a cart containing their products to take a code at all, since even an order-level discount effectively reprices their items on the invoice.
That’s a Controller rule in PromoLock. First register the collection under rule variables, then build the rule: trigger on all codes, condition Product from collection · Has any of your protected collection, action Block, with a message that says why. Something like “Discount codes can’t be applied to orders containing BrandName products.”
Because Controller rules run at checkout, this covers every code from every source, including the ones other apps generate. That’s the enforcement layer the native route was missing.
Which one do you want?
Quick test: if a customer has a protected item plus regular items in one cart, should their code work on the regular items?
Yes → cart group exclusion. The code applies where it’s allowed. No → Controller rule. The presence of the protected product locks the whole order down.
Plenty of stores end up using both, for different collections. The collab gets the hard rule; new arrivals get the soft exclusion.
The part that makes this stick
Policies drift when they live in people’s heads. The nice property of doing exclusions this way is that they’re set once and enforced mechanically — the next seasonal code, built in a hurry in November, inherits the same protections without anyone remembering anything. That’s really the whole argument for enforcement over configuration, and it applies to stacking and sale items just the same.