When a Sylius promotion not applied problem appears, the visible symptom is simple: a customer expects a discount, but the order total does not change. The cause is often less obvious. Promotions are evaluated through a combination of eligibility conditions, configured actions, channels, dates, coupon requirements, and the current order state. A promotion can be enabled in the admin area and still be ineligible for the exact order being tested.
The safest approach is to trace one reproducible cart from its channel and currency through every rule and action. Avoid changing several promotion settings at once. That can make a temporary result look like a fix while hiding the actual configuration or customization problem.
Start with one controlled test order
Before checking configuration, record a single failing scenario. Include the storefront channel, currency, customer status, products and variants in the cart, quantities, subtotal, coupon code if relevant, and the expected discount. Test in a private browser session where possible so an old session or previously applied coupon does not affect the result.
Also establish exactly what “not applied” means. The promotion may be absent altogether, appear with a value of zero, apply only after a page refresh, or be applied and then removed after an address or quantity change. These are different failure patterns:
- Missing from the start usually points to eligibility, dates, channel assignment, or coupon entry.
- Visible but worth zero can point to an action setup, an amount basis, rounding, or an incompatible order total.
- Applied and later removed often indicates that a later cart change makes a rule false.
- Different results by storefront commonly indicate channel-specific configuration, currencies, prices, or custom code.
Confirm that the promotion is active in the tested channel
First verify the plain configuration details. Check that the promotion is enabled, that its start and end dates include the current time, and that it belongs to the channel used by the test cart. A promotion configured for one channel does not automatically apply to another storefront, even where the catalog looks similar.
Time settings deserve extra attention on production systems. Server timezone, application timezone, and the timezone used when an administrator entered the dates can create an apparent promotion failure near the beginning or end of a campaign. Test well inside the intended date range before treating the issue as a timezone bug.
Next, check the promotion priority and exclusivity settings. Priority determines the order in which eligible promotions are processed. Exclusivity can prevent other promotions from being applied once an exclusive promotion qualifies. If one discount consistently wins while another disappears, do not assume the missing promotion is broken; inspect how those promotions are intended to interact.
Read every eligibility rule literally
Promotion labels are written for people, but rules are evaluated by the application. Review each rule as a condition that must be true for the current order. A promotion intended as “10% off summer items over $100” may require both a minimum order amount and the presence of qualifying items. If either condition fails, the whole promotion is ineligible.
Common rule mismatches include:
- The threshold is calculated from a different amount than expected, such as item total rather than a total including delivery charges.
- The rule targets a taxon, product, or variant that is not actually present in the cart.
- The customer must belong to a group or be logged in, but the test uses a guest checkout.
- The rule is limited to a specific channel or currency.
- A usage limit has been reached, either globally or for an individual customer.
- A custom rule checker has extra conditions that are not visible in the admin wording.
Temporarily simplify the test in a safe staging environment. Use one known qualifying variant, a simple quantity, and no competing promotion. If the promotion works in that case, add conditions back one at a time. This is far more reliable than repeatedly adjusting thresholds in production.
Check coupon code behavior separately
A coupon-based promotion has an additional failure point: the code must be valid and successfully attached to the order. Check spelling, case handling in the storefront implementation, start and end dates, usage limits, and whether the code has already been consumed.
Do not rely only on the message shown to a shopper. A custom checkout theme or API integration may fail to submit the code even when the interface makes it appear accepted. Confirm the order data after submitting the coupon. If a code is present but the promotion still does not apply, continue with the promotion rules and actions. If the code never reaches the order, the problem is in the form, request handling, API layer, or customization rather than promotion evaluation itself.
Verify the promotion action can affect this order
Rules decide whether a promotion is eligible; actions decide what the eligible promotion does. A correct rule with an unsuitable action can produce no visible discount. Review the action type and its configuration carefully.
For a percentage discount, confirm which items or totals are in scope and whether excluded products are expected. For a fixed amount, make sure the amount is sensible for the tested currency and order total. For an item-based action, confirm that the targeted item is eligible and that quantities meet the action’s conditions. A discount cannot reduce an already-zero applicable total below zero, so a small eligible value can also make an action look ineffective.
Where a project has custom promotion actions, inspect the service configuration and business logic as well as the admin settings. A custom action may be registered correctly but calculate against the wrong adjustment target, use outdated Sylius extension points, or assume data that is absent in a guest order. These cases require code-level tracing rather than further admin changes.
Look for stale order state and recalculation issues
Promotions are closely tied to the current order. If product quantities, customer identity, shipping selections, addresses, or coupon codes change, the order may need recalculation. A frontend that updates its display without correctly refreshing the order can show stale totals. Conversely, a full refresh can remove a discount that was displayed before all eligibility data was available.
Compare the request that changes the cart with the order state returned afterwards. Review application logs for exceptions around promotion processing, custom listeners, and order recalculation. Test the same cart through the standard storefront flow if the issue occurs in a headless, mobile, or bespoke checkout. A working standard flow strongly suggests an integration issue rather than a core promotion configuration issue.
Cache can complicate diagnosis too. Cached product data, customer-specific pages, or outdated frontend assets may display an old price or promotion message. Clear only the relevant application and frontend caches according to the project’s deployment process, then retest with a new session. Do not broadly clear production caches during a live campaign without considering the customer impact.
Use logs and code changes to narrow the cause
If the configuration appears correct, check what changed before the issue started. A Sylius or Symfony upgrade, a custom plugin release, a pricing import, a channel change, or a modification to order processing can all alter promotion behavior. Compare a known-working environment with the failing one: installed package versions, environment settings, promotion records, channel configuration, and custom services are useful starting points.
For a code investigation, trace the promotion eligibility and action path for the specific order rather than adding broad debug output to every checkout request. Keep logs free of payment, address, and customer data where possible. The aim is to establish whether the promotion is excluded by a rule, skipped because of priority or exclusivity, or applied but overwritten later by another customization.
When a Sylius promotion issue needs specialist help
Get help promptly if a live campaign is losing sales, discounts are being applied incorrectly, or the problem began after a deployment or upgrade. It is also sensible to escalate when the store uses custom promotion rules, ERP-driven pricing, multiple channels, a headless storefront, or custom order processing. In these setups, changing the admin configuration may mask a deeper defect.
For targeted investigation of promotion logic, checkout customizations, and upgrade-related commerce issues, see Sylius bug fixing. Provide a reproducible cart, the expected and actual totals, affected channel and currency, relevant promotion settings, the time the issue began, and any recent releases. That information makes it much faster to distinguish a configuration mismatch from an application-level bug.
Frequently asked questions
Why is my Sylius promotion enabled but not applied?
An enabled promotion can still be ineligible. Check the active date range, channel assignment, rule conditions, coupon status, usage limits, priority, exclusivity, and whether the action can affect the current order.
Can two Sylius promotions apply to the same order?
They can, depending on configuration. Priority and exclusivity affect how promotions interact, so test competing promotions together rather than reviewing each one in isolation.
Why does a discount disappear after I change the address or cart quantity?
The change may cause a rule to become false, such as a minimum order amount, customer condition, product requirement, or a custom eligibility check. Recheck the final order data after the change.
Should I change promotion settings directly on a live store?
Use caution. For a time-sensitive campaign, capture the existing settings first and make one reversible change at a time. A staging reproduction is safer when custom rules or integrations are involved.