Adobe Commerce price rules: why the wrong rule type quietly breaks a promotion
Adobe Commerce price rules: why the wrong rule type quietly breaks a promotion

Most promotions that disappoint were built correctly and placed wrongly. The discount works in testing, the campaign goes live, and nothing moves — because the rule fires in the shopping cart when the offer needed to be visible on the category page, or because a coupon was designed into an offer that can never carry one.
Adobe Commerce gives you two instruments for discounting, and they are not variations on a theme. Catalog price rules and cart price rules apply at different moments, are seen in different places, and disagree on whether a coupon is even possible.
Table of contents
- What is a price rule in Adobe Commerce?
- Why the difference between the two rule types decides the promotion
- What a condition can be built from
- Integration across Adobe Experience Cloud
- What to plan for: editions, stacking and dates
- Conclusion: why price rules matter
What is a price rule in Adobe Commerce?
Adobe’s definition is usefully mechanical: a rule is a collection of conditions that apply changes in prices to products when one or all of them are met. A single rule can carry many conditions, and it fires when all of the statements are true or when any of them are.
A rule is scoped to the websites where it is available and the customer groups it applies to, so one catalog can price differently for different audiences without duplicating products. A rule can also be given a start and an end, so a seasonal promotion stops on the date you defined rather than the day someone remembers to switch it off.
Why the difference between the two rule types decides the promotion
The question that separates them: has the product reached the cart yet?
The catalog rule — discounting before the cart. A catalog price rule offers products at a discounted price based on defined conditions, and its discount goes into effect before the product is placed into the shopping cart. The shopper sees a special or promotional price on the product itself, which is why it supports browse-and-discover promotions.
The consequence people miss is a hard one. Adobe states it directly: catalog price rules do not use coupon codes, because they are triggered before a product is placed into the shopping cart. No configuration changes this: a campaign built around a code is a cart rule campaign.
How the discounted price is arrived at matters too. Adobe defines the final product price as the minimum of the relevant prices — regular price, any tier price for the group, any special price, and the catalog price rule — plus the minimum price of each required custom option. A catalog rule does not automatically win: the lowest number takes the sale.
The cart rule — discounting inside the cart. A cart price rule applies discounts to items already in the shopping cart. Adobe describes two ways it can trigger: automatically when the conditions are met, or when the customer enters a valid coupon code. When it applies, the discount appears in the cart beneath the subtotal, so the shopper sees a line rather than a changed price tag.
Cart rules also reach further into checkout than teams expect. If a coupon rule has conditions naming particular shipping or payment methods, those conditions can only be satisfied once the shopper has chosen them — so the coupon becomes applicable in the last step of checkout, not in the cart.
What a condition can be built from
Conditions turn a discount into a targeted offer, and the material differs by rule type. A cart rule condition can combine cart and product attributes, and if you leave conditions empty the rule applies to every product in the cart. One limit matters before design: customizable options cannot be referenced in cart price rule conditions.
Two further constraints catch teams out. A product attribute is not available to a rule condition by default — it has to be marked as usable in promotion rule conditions first, and until it is, it will not appear as an option. And customer segments and customer groups are not interchangeable: Adobe documents customer groups as usable in both catalog and cart price rules, while customer segments work in cart price rules but not catalog price rules. A promotion designed around a segment cannot be delivered as a catalog rule.
Integration across Adobe Experience Cloud
With the Audience Activation extension in place, a cart price rule condition can be an audience built in Adobe Real-Time Customer Data Platform — and that audience is assembled from systems the storefront never sees, such as ERP, CRM and point-of-sale data. Adobe frames the outcome as unique offers in the cart, hero banners aimed at that shopper, and modified pricing through promotional offers.
The nuance is ownership: the audience is a Real-Time CDP object, not a Commerce feature — Commerce consumes it as a condition. That is why we scope the data path and the promotion design together in our Adobe Commerce work: the audience must exist and be activated before a rule can reference it.
What to plan for: editions, stacking and dates
Some of this is Adobe Commerce only, and the edition boundary is not where people guess. Linking a catalog price rule to a dynamic block is documented as an Adobe Commerce capability, and so is using customer segments in price rules. Adobe’s edition markers run feature by feature, so a capability present in one edition is not implied in the other.
Date handling differs by edition on the same rule type. Adobe documents the start and end dates of a catalog price rule as a Magento Open Source setting, and states that in Adobe Commerce those fields have been removed from the rule’s configuration page and cannot be modified there directly — the schedule is set through a scheduled update instead. A runbook written against one edition will mislead a team running the other.
Rules stack unless you stop them. When several rules match one product, multiple discounts can apply and compound. Adobe’s control works only if priorities are set and no two rules share one — otherwise it does nothing, and the compounding shows up in a margin report.
Usage limits have a blind spot. A per-customer usage limit applies to registered customers in the selected groups and does not apply to guests or to customers shopping without logging in. A "one per person" offer is not one per person for anonymous traffic.
Conclusion: why price rules matter
Price rules are where commercial intent meets platform behavior, and the two most expensive mistakes are cheap to avoid: choosing a catalog rule for a coupon campaign, and assuming a feature documented for one edition exists in the other.
We design promotions against what the platform actually does: the right rule type for the moment you want to influence, conditions built on attributes that exist, priorities set so discounts do not compound, and the edition boundary written down before anyone promises a campaign. Most catalogs need one pass of 2–3 weeks to get rule types, priorities and the edition boundary straight; after it, promotions ship on the same two-week release cadence as the rest of the store.
Unlock the power of Adobe Solution with Softwhale.
Unlock the power of Adobe Solution with Softwhale.
Explore how Softwhale’s expert Adobe solutions can help you build scalable and personalized digital experiences. Dive deeper into insights and best practices tailored specifically to your industry. Stay informed with our latest blog posts on Adobe trends, strategies, and innovations.