Conditions & Rules

What Conditions Do#

The idea#

A discount without conditions applies to every product you targeted, every time, for as long as it is Active and inside its schedule. Conditions narrow that. They are extra checks that have to pass before the discount is allowed to reduce the price.

Conditions live in the Conditions section, at the bottom of the discount form under Discount period. When a discount has none, the section reads:

No conditions. This discount applies whenever it is active and in schedule.

Conditions are optional, and most discounts never need one.

What conditions do not do. They do not choose which products get the discount, which is the Included products section. They do not set the dates a discount runs, which is Discount period. And they do not decide which discount wins when two of them match the same item, which is Priority, where the lowest number wins and only one product discount applies per item.

The three condition types#

xDiscount offers exactly three conditions. There are no others, and none are hidden behind an upgrade. Every one of them is on every plan, Free included.

How many times each one can be used#

Each condition can be used once. A discount can carry one Item quantity row, one Cart value row and one Inventory row, never two of the same. A type another row has already taken is still listed, greyed out and marked as already used, so you can see why you cannot pick it. Your own row’s current type is never greyed out.

When all three are in use, Add condition switches off and says so:

Every condition is already in use. Remove one to add a different condition.

Building Conditions#

Adding a condition#

Each row is numbered and has a drag handle on the left, Reorder condition 1, Reorder condition 2, and so on. Drag rows to reorder them, because the order matters, and the section says so directly:

Configure the conditions a cart must meet for this discount to apply. Choose a condition type, then set its values. Each condition type can be used once per discount.

To delete a row, click the delete button at its top right, Remove condition 1. There is no confirmation step, and nothing else on the form is affected.

Minimums and maximums#

Every condition is a range, not a comparison. There is no “greater than” or “equals” picker. You give a lower bound, an upper bound, or both.

• Both bounds are inclusive. Minimum items of 3 qualifies at exactly 3.
• Both bounds are independent. Fill in only the minimum for an open-ended floor, or only the maximum for a ceiling.
• 0 is a real bound, not an empty field. A maximum of 0 means exactly that.
• You must fill in at least one of the two. Leaving both empty blocks the save with “Set a minimum, a maximum, or both.”

Cart value uses your store’s own currency field, so the amount is shown and typed in the currency you sell in. There is no currency picker, and no symbol is hardcoded into the form. Item quantity and Inventory are whole numbers.

Negating a condition#

Each row has a Negate this condition checkbox. Ticking it flips that row only, so the discount applies when the condition is not met.

A negated Item quantity of “at least 5” qualifies carts of 0 to 4 items and rejects carts of 5 or more. Negation never leaks into the rows above or below it.

On an Inventory row the checkbox explains itself, because the row removes variants rather than judging a cart:

Skips the variants INSIDE the range instead of outside it.

So a negated Inventory row set to 5 to 10 discounts everything except the variants holding between 5 and 10 units.

Joining rows with and / or#

The first row has no join control, because it starts the chain and there is nothing to join it to. Every row after it has a Join dropdown with two lowercase options, and and or.

Rows fold strictly from top to bottom. There is no grouping, no brackets and no operator precedence. Each row takes the result so far and joins the new row’s result to it. This is not ordinary boolean algebra, and the difference is real.

Take these rows:

xDiscount reads that as row 1 or row 2. Add a third row joined with and and it becomes ( row 1 or row 2 ) and row 3, not row 1 or ( row 2 and row 3 ). If you want a specific grouping, put the rows in the order that produces it when read top to bottom.

An Inventory row is always joined with and. Its Join dropdown is locked, with the reason printed beside it:

Inventory can only narrow the discount.

That is not a limitation being hidden. An inventory row works by removing variants from the discount’s reach before anything else is read, so “low stock or a big cart” could never mean what it says, because the shopper with the big cart would never reach the comparison. Under and, the control and the behaviour agree. Rules that arrive from a connected AI assistant are held to the same rule and refused with “Inventory narrows the discount, so it has to join with AND.”

The Inventory Condition, in Full#

This one behaves differently from the other two, and the difference is worth two minutes of your time, because it changes what you can expect from it.

It applies per variant, never per product#

Stock is counted per product variant. A t-shirt whose Small holds 0 and whose Large holds 40 has no single stock figure, and xDiscount never invents one. An Inventory condition with a minimum of 5 leaves the Large discounted and skips the Small, on the same product, in the same cart, at the same moment.

It is resolved by the app, not read at checkout#

A Shopify discount function cannot read stock. The figure does not exist in what Shopify hands it at checkout, and the only other place a number could come from is the shopper’s own browser, which can be edited.

So xDiscount answers the question somewhere the number is real, on the server, before checkout. When it resolves an inventory condition it reads each targeted variant’s stock from Shopify, works out which variants fall outside your range, and writes that list of variants into the configuration on your products. At checkout those variants are simply not part of the discount any more. Nothing is re-checked in the cart.

When it is checked#

The builder prints the cadence next to the row, and it is exact:

Checked per product variant when this discount syncs, and once a day after that. Variants outside the range are skipped until the next check.

In practice:

What that means when your stock moves during the day#

The answer is a snapshot, and it can be up to a day old. Both directions are real, and neither is hidden from you:

• A variant that sold out after the last check keeps the discount until the next one. If you set the condition to protect margin on low stock, it can run a little past where you wanted.
• A variant you restocked after the last check stays skipped until the next one. Shoppers see no offer on it in the meantime.

The fix for both is the same, open the discount and click Save. That re-reads stock there and then, for every product the discount targets, and the answer is correct again from that moment.

Variants that do not track inventory#

A variant with inventory tracking switched off reports no stock figure at all. Those variants are never skipped, whatever bounds you set. “0 in stock” and “not tracked” are not the same thing, and treating them as the same would quietly drop every digital product, service and untracked item out of your discounts.

The checkbox and the condition are the same mechanism#

Skip products that are out of stock, in the Discount configuration section, is the special case “at least 1 in stock”. It is resolved at the same moments, from the same stock read, and it obeys the same rule about untracked variants. Its own help text on the form says “Checked at save time. Variants with no stock won’t be discounted.”, and the daily refresh covers it too.

Scheduling Is Not a Condition#

There is exactly one place to put a discount on a calendar, and it is not the Conditions section.

Open the Discount period section and fill in Start date, End date, or both. Both bounds are inclusive whole days and each works independently, so a start with no end runs forever, and a start equal to the end is a legal one-day window. Underneath, the form says whose calendar it uses:

Dates follow your store’s timezone, not your own.

There is no date condition to add. The Condition dropdown offers Item quantity, Cart value and Inventory, and nothing else. Two controls writing one window is how a discount ends up with two answers about when it runs, so the window lives in Discount period only.

If you have an older discount with a date condition, it still works and it is still editable. That row shows as Date range (set in Schedule) with its From and To fields intact, and a line underneath:

New discounts set their dates in Schedule. This condition is kept so discounts saved earlier keep running as they were.

Nothing can be switched to that type, and a new row can never be one. Moving an old discount over is a two-minute job. Copy the dates into Start date and End date under Discount period, delete the condition row, and Save.

What Qualifies and What Does Not#

One condition, Item quantity, minimum 3, maximum 5#

The same row with Negate this condition ticked flips every answer in that column.

Two conditions, Item quantity or Cart value#

Adding an Inventory row#

An Inventory row does not appear in that table at all, because it is settled before the cart is read. Add Inventory, minimum 5, to the discount above and the variants holding fewer than 5 units are no longer part of the discount. The quantity and cart-value rows never get a chance to rescue them.

Things that never qualify#

In every unclear case, xDiscount declines to discount. A discount that wrongly applies costs you money on every order. One that wrongly does not apply is visible to you and fixable in a minute.

What Shoppers See#

The card and checkout read the same configuration#

Once you have added the xDiscount offer block to your product template, the storefront offer card lists the conditions underneath the offer. The card is included on every plan, Free included. That list is not a second description written by hand. The card and the checkout discount read the same saved configuration, so what a shopper is told and what they are charged cannot drift apart.

Rows after the first carry their own connector, and or or, printed in front of them, in the order you arranged them in the admin.

Conditions are never used to explain a failure at checkout. The label beside an applied saving is always the single word xDiscount. It never spells out mechanics, amounts, or which condition was missed.

Saving and Error Messages#

Errors appear after your first click on Save, in red under the row that caused them. At the same time a banner headed This discount can’t be saved yet appears at the top of the page, and the toast “Fix the highlighted fields before saving.” appears.

Nothing is written to your store until every row passes.