Managing Magento Catalog Price Rules: Creation, Indexing, and Cache Considerations

Problem: Discounts not showing after rule creation

After you create a catalog price rule in Magento Admin, the product prices on the storefront may still display the original amount. This happens because Magento does not apply the rule until the catalogrule indexer runs and any full‑page cache is refreshed.

Creating a catalog price rule

Navigate to Marketing → Promotions → Catalog Price Rules and click Add New Rule. Fill in:

• Rule Information: Name, Description, Status (Active), Website, Customer Groups, From/To dates.
• Conditions: For example, Category is Clothing.
• Actions: Apply Percent of product price discount with Discount Amount 15, and optionally set Stop Further Rules Processing to No.

Save the rule. At this point the rule exists in the database but is not yet used for price calculations.

Applying the rule with the indexer

Magento stores the computed discounted prices in the catalogrule_product_price table after the catalogrule_rule indexer runs. Trigger it from the command line:

bin/magento indexer:reindex catalogrule_rule

Run this command as the file‑system user that owns the Magento code (typically www-data or the deploy user). No additional permissions are required beyond being able to execute the Magento CLI.

After the indexer finishes, visit a product page that matches the condition (e.g., any item in the Clothing category). The displayed price should now reflect the 15 % discount.

Combining multiple rules and priority

Magento evaluates all active catalog price rules in ascending order of the priority field. The rule with the lowest priority number is applied first, unless a rule has Stop Further Rules Processing set to Yes, which prevents any lower‑priority rules from being considered.

For example, you could have a site‑wide 10 % discount (priority 1) and a category‑specific 20 % discount for Clothing (priority 2). With both rules set to continue processing, Magento would apply the 20 % discount because it is higher and processed after the site‑wide rule. If you want the site‑wide discount to block the category rule, set Stop Further Rules Processing to Yes on the site‑wide rule.

Performance impact and caching considerations

For small catalogs the indexing step adds only a few seconds. Large catalogs with hundreds of thousands of products and many price rules can see the indexer take minutes, during which the catalogrule_rule indexer locks the table, potentially delaying other indexers.

To avoid frontend slowdown, schedule the reindex during off‑peak hours using cron or Magento’s built‑in scheduler:

bin/magento cron:run --group index

Even after a successful reindex, full‑page caches (Varnish, Redis, or Magento’s built‑in cache) may serve stale HTML that still shows the old price. Clear the relevant cache after reindexing:

bin/magento cache:clean FPC

or flush all caches with bin/magento cache:flush if you are unsure which store view is affected.

Verification steps

1. Create or edit a rule in the admin and save it.
2. Run bin/magento indexer:reindex catalogrule_rule.
3. Check the frontend price for a matching product.
4. If the price is unchanged, flush the full‑page cache and reload the page.
5. Optionally inspect the database: SELECT rule_id, price FROM catalogrule_product_price WHERE product_id = YOUR_PRODUCT_ID; should show the discounted price and the rule’s ID.

Limitations

• Changing a rule’s conditions does not automatically update frontend prices; you must reindex again.
• If you rely on asynchronous indexers (e.g., split‑database mode), ensure the indexer group is configured to run on the appropriate node.
• The catalog price rule engine works only with simple, virtual, configurable, bundle, and downloadable product types; it does not apply to gift cards or custom options that affect price.

Actionable closing

To keep discounts accurate, treat the catalogrule indexer as part of your promotion workflow: after any rule creation, modification, or deletion, run the indexer, then clear the full‑page cache. Automate this sequence in a deployment script or a cron job that runs during low‑traffic windows, and monitor the indexer’s timing to ensure it stays within your maintenance window.