Feature Request: Consistent Rule Conditions Across Checkout Blocks

Summary

Make the available display-rule conditions consistent across Checkout Blocks, particularly for product-related conditions such as Product Collection, Product Tag, Product Type, Vendor, and Metafields.

Problem

Checkout Blocks currently exposes different product conditions depending on the type of block or customization being configured.

For example, Product Collection can be used as a condition in some checkout customizations, such as shipping-related rules, but may not be available as a condition when configuring other blocks that also operate in the context of products or cart line items.

Similarly, other product attributes, such as tags or product type, are available in some contexts but not others.

This makes it difficult to implement a single business rule consistently throughout checkout.

Example

A merchant may have a collection defined by to group products that are “pickup in store only”.

They can use the collection as a condition to prevent shipping for those products, but may not be able to use the same collection condition to display a general checkout message explaining why shipping is unavailable.

Instead, they may have to use a different representation of the same business rule.

This results in duplicated logic and makes the configuration unnecessarily difficult to maintain.

Requested improvement

Provide a consistent product/cart condition model across Checkout Blocks.

Where a block operates in a context in which a product or cart line item is available, merchants should be able to use the same relevant product attributes as conditions, including:

  • Product collection
  • Product tag
  • Product type
  • Product vendor
  • Product metafields
  • Product ID / variant ID

Ideally, these conditions should support a consistent set of operators such as:

  • Is
  • Is not
  • Contains
  • Does not contain

The available conditions could still be constrained where a particular condition genuinely makes no semantic sense, but the current arbitrary differences between block types should be avoided.

Why this matters

Checkout Blocks is increasingly being used to implement business logic rather than simply cosmetic checkout changes. Merchants therefore need to be able to express the same business rule consistently across multiple checkout components.

A unified condition model would:

  • Reduce duplicated business logic.
  • Make checkout configurations easier to understand and maintain.
  • Reduce the need for workaround metafields or tags.
  • Make the Checkout Blocks UI more predictable.
  • Allow merchants to provide clearer contextual messaging when a checkout restriction is triggered.

In short, if Checkout Blocks can determine that a cart contains a product belonging to a particular collection for one purpose, merchants should be able to use that same fact when deciding whether another checkout block should be displayed.

Hey @Martin_Davies, thanks for this. I definitely get where you’re coming from. There’s some friction here for sure.

The difference is in what data each system has access to. Shopify Functions can check collection membership through fields like inAnyCollection in their input queries. Checkout Blocks display rules currently don’t include a Product collection condition, even though collection-based conditions are available for some Shopify Function-based rules.

I’m happy to pass this feedback directly along internally though for sure. Two quick questions so I can capture exactly what you need:

  1. Which block types are you running into this with most, such as Dynamic Content or Custom Fields?
  2. For a mixed cart, should the block display if any item belongs to the collection, or only if every item does?

For now, product tags are probably the simplest option that works across both. A product metafield can work too, but it needs to be set up specifically as a Checkout Blocks display-rule metafield.

It’s not really one particular block type that I’m finding problematic. The issue is more that, in practice, you often need to use multiple block types together to implement a single piece of conditional checkout logic.

Imagine the following scenario, where I want to:

  1. Use a Hide Payment Function because an item in the cart requires collection rather than shipping.
  2. Display an alert next to the affected line item using a Line Item Content Block.
  3. Display a Dynamic Content Block at the top of the checkout explaining to the customer why payment isn’t currently available and what they need to do.

Those three things are really part of the same business rule and customer experience, but the simplest way to achieve it would currently be:

  1. Use Product collection as the condition for hiding the payment details.
  2. Use Product tag for the line item alert.
  3. Use Product type as the condition for displaying the Dynamic Content block.

In this example, I have to maintain two separate pieces of product data and a dedicated collection to represent what is fundamentally one business rule.

That’s the part I find problematic. The conditions available to different checkout components aren’t sufficiently consistent to allow a single business rule to be expressed coherently across the checkout.

So my broader feedback would be that checkout conditions need to be treated as reusable conditions that can be applied consistently across different block/function types, rather than each type having its own slightly different set of conditions.

Hey @Martin_Davies, I appreciate this. I get what you mean about expressing the same business rule across Functions, line-item messaging, and cart-level content without meaning you have to have separate product classifications for each.

I’ve confirmed that the current builders expose different product rule sets on my end here, but your example also clears up the mixed-cart behaviour.

I’m passing this along with collection membership as features requests for you, along with the broader request for equivalent product conditions and operators across Checkout Blocks contexts where the underlying data is available. I don’t have a timeline I can share, but just wanted to confirm I’ve sent this up internally. Let me know if I can help with anything else.

Appreciated. Thank you.

No problem @Martin_Davies - just going to mark this thread as closed, but let me know if I can help out further.