Magento Open Source price rules and promotions

The most important thing to settle before you build a campaign is which rule wins when several apply to the same product or basket. In Magento Open Source, catalog price rules change the price a shopper sees on product, category and search pages, and cart price rules then act on the basket total, shipping and item discounts at checkout. The two rule types are evaluated at different points in the purchase path, so a shopper can see a discounted price on a product page and still receive a different final amount in the cart. Your team should document the intended result for each campaign as a worked example, then check that the store produces exactly that result.

Priority is the setting that decides the order in which rules are applied within each type. Lower numbers are generally treated as higher priority, but you should confirm this convention, and the exact handling of ties, in the current Open Source documentation before you write any internal guidance. Pay attention to the discard subsequent rules option as well. When it is enabled on a rule that matches, later rules with lower priority should not be applied to that item. Whether this option applies across catalog rules, cart rules or both, and how it interacts with a stacked coupon, are points to verify in a test store rather than assume from memory of earlier releases.

Scope limits which shoppers and sites a rule can touch. Each rule is assigned to one or more customer groups and one or more websites, so a retail promotion and a wholesale price change can coexist in the same catalog without leaking into each other. Scope errors are a common source of incidents: a rule assigned to the wrong customer group can discount B2B orders, and a rule that is not assigned to a website in a multi-store setup will never fire there. Build a scope matrix listing every rule, group, website and date window, and have a reviewer sign it off before launch.

Coupon usage limits add a second layer of control for cart price rules. A rule can be restricted by total uses across all customers and by uses per customer, and a rule can be set to generate coupon codes or to require a single shared code. Limits are counted when orders are placed, so you should test what happens when a shopper holds a coupon in an open cart while the limit is reached by others. Ask your implementation team to confirm how usage counts are recorded under your checkout and payment setup, and to plan how support will handle a customer who reports a rejected code.

Illustrative example: a store runs a 10 percent catalog rule for a category at priority 1 and a fixed amount cart rule for orders over a set value at priority 2, both assigned to the retail group on the main website. A test script should record the product price shown, the cart subtotal, the discount lines at checkout and the final total for a retail shopper, a wholesale shopper and a guest, then compare each result with the written expected values. Repeat the test after any change to priority, scope or the discard option, because these settings often change the outcome in ways that are not obvious from the admin screens.

The main constraint for a promotions calendar is that Magento Open Source does not provide the audience targeting and scheduled staging controls that Adobe Commerce documents for campaign work. Catalog price rules and cart price rules in the open source edition can be limited by customer group, website, date range and coupon code. They do not offer the segment-based personalization that Adobe Commerce documents, and they cannot prepare a set of rules and related content in a staging area and publish them together at a chosen time. Before you commit to a launch plan, confirm the current feature coverage for each item against the Open Source documentation and the release notes for the exact version you will run, because edition boundaries can change between releases.

Each gap affects the launch calendar in a different way. Without scheduled staging, every rule must be entered with its own start and end dates, and a campaign made up of several price rules, coupons and promotional blocks cannot be reviewed as one unit and switched on together. Changes made during review can go live immediately if they are saved in the admin. Without segment-based targeting, an offer for a specific shopper group has to be modeled as a customer group or a distributed coupon, which means someone maintains group membership and coupon exports. Rule priority and the option to stop processing later rules also interact with dates, so overlapping campaigns need a written order of precedence that the calendar owner approves.

Teams usually choose one of three workarounds. Time-boxed rules managed by staff keep everything inside the existing admin: rules are created with fixed dates and staff enable or disable them at set times. The trade-off is ongoing staff time, the risk of errors around time zones and missed switch-offs, and a weak approval trail unless you add a written process. Custom development can add segment logic or a scheduler in a custom module. This gives the most control but carries build and test cost, and Adobe's upgrade guide names customizations as a driver of upgrade effort, so each patch cycle will need regression checks. A separate campaign tool can own audiences and schedules and push prices or coupons into the store through an integration. This adds an integration to build and maintain, a data sync between the tool and the cart, and another access model to review, including whether the tool touches payment-adjacent data in your PCI DSS scope.

Before you choose, list every campaign on the calendar and mark which edition feature it needs. Ask each candidate partner for a quote that separates one-time build work from recurring costs such as maintenance, retesting after patches and staff training, and ask who owns the rules after launch. Test overlapping dates, time zone boundaries and coupon limits in a non-production environment that matches your production version. Record the decision and the owner for each workaround so that the next campaign does not depend on one person's memory of how the rules were set up.

Start the pre-launch test plan with overlapping rules, because that is where most promotion errors appear. List every catalog price rule and cart price rule that will be live during the campaign window, then record each rule's priority, customer groups, websites and whether it stops later rules from applying. Build test carts that trigger two or more rules at once, and confirm that the discount Magento Open Source applies matches the written expectation for each combination. Next, test coupon limits: total uses per coupon, uses per customer, and what happens when a coupon is applied to a cart that has already reached its limit. Run each case as a guest and as a logged-in customer in each relevant customer group, since group membership changes which rules match.

Full-page caching is the step teams most often skip. For self-managed installations, Adobe documents Varnish as the full-page cache accelerator, so your team must configure it and purge it whenever promotions change. If Varnish serves a cached product or category page after a rule goes live, shoppers see the old price even though the rule is correct in the admin. Test this in staging by publishing a rule, purging the affected cache, and then loading the same pages as a guest and as a logged-in customer, since cached responses can differ by visitor type. Adobe's requirements for 2.4.8-p5 list Varnish 8, so confirm the version and cache configuration for your release against the Varnish documentation and the Adobe cache guide before you rely on the test results.

Tax-inclusive price display changes how a promotion looks to the shopper. Test each promotion on the product page, in the mini cart, in the cart totals and at checkout, with price display set to include tax, and compare the discounted price with the tax shown in the order summary. Use test addresses in each tax zone the store sells into, because the same rule can produce different displayed totals once tax is calculated on the discounted amount. Check that the order total, the invoice and the confirmation email all agree. Tax class and rate setup belongs to the tax configuration work, so this check covers only how promotions interact with it. Record the expected net, tax and gross figures for every test cart before you run it, so reviewers can compare the output with a fixed reference.

Where the store runs more than one website or currency, add those cases to the matrix. Price rules are scoped to websites and customer groups, so confirm that a rule on one website does not appear on another, and that discounted prices convert correctly in each displayed currency. Confirm with your implementation team whether the discount is calculated in base or display currency in your configuration, and test both paths if the answer is unclear. Document the expected result for each test case before execution, keep a retest log after every cache purge or rule change, and name one owner who approves the promotion for launch. In a quote, ask how many test cases, environments and retest cycles are included in the scope.