I can confirm this works but this made me realise that now although a product is part of the products connection on the collection it does not mean that the whole product is part of the collection like it used to prior to this change. Now the app needs to also check if the variantsInCollection or variantsInCollectionCount to confirm if the collection applies to the product or only some of the variants of the products.
Any way to activate new Collection UI for a specific dev store?
It takes about 4h from creation to get the new UI. If you still do not see it, message me with your shop number.
@Diana_Shopify This has been rolled out onto one of our “Client Transfer” stores that we’re actively working on. Unfortunately we’ve come across a UI Bug.
Anytime we load a collection in the admin, it not shows 0 products, even though there are clearly products on the front-end.
It we try and edit the collection, we get an error message saying “1 condition needs to be fixed” (not very helpful).
It seems that all of our conditions are defaulting to an “AND” operator *(presumably because they didn’t support operators at a condition level before).
*
But alas, the UI is saying that it’s invalid and asking us to change it to “OR”, even though there’s only 1 value..
Changing it to “OR” does seem to bring it back to life, but we’ve now got to do this anytime we edit a collection for the first time since this update..
Thanks for flagging. We’re working on a fix.
Hey, is there a way to check a variant’s collection membership in Liquid?
Our app uses an app embed block to display information based on products or variants targeted through collections. With the new model, collections can include specific variants, but Liquid appears to expose collection membership only at the product level.
Is variant-level collection membership available in Liquid, or is support planned?
We build Supergrid by Depict (collection merchandising, listed app). We’ve completed our migration to 2026-07 and the new sources model is genuinely more expressive – but reading it back at scale has some rough edges we’d like to flag, with repro details:
1. inclusion.selections can’t be read via bulk operations at all. Any bulk query touching sources[].inclusion.selections is rejected at submission with “Queries that contain a connection field within a list field are not currently supported”. Typed conditions ride along inline fine (they’re plain lists), but manual variant picks – exactly what the new admin UI’s variant picker creates – are only reachable via per-source node() queries outside bulk. For apps that sync whole shops via bulk (as recommended), this forces a second, separately rate-limited fetch pass. Ask: support connections under list fields in bulk, or flatten selections into child JSONL rows with __parentId like every other connection.
2. There’s no bulk-readable representation of resolved variant membership either. Product.variantsInCollection(collectionId:) requires the collection argument, so it can’t enumerate variant membership in a products/collections bulk. Combined with (1), the only scalable option is re-implementing the condition evaluation client-side against our own variant data – which works, but means every app must replicate the rule engine’s semantics (price currency handling, inventory semantics, string matching) and hope they match Shopify’s.
3. Condition-driven variant membership changes emit no collection-side signal. No collections/update webhook when e.g. a variant price change flips a variant in or out of a rule-based collection (the product side does fire products/update, which is what we key on now).
Happy to share bulk operation IDs and timestamps for any of these if useful to the team.
Following up on my post above with a concrete correctness issue we hit while validating our client-side derivation against the API.
Product.variantsInCollection documents its sentinel clearly: “Returns null for products whose collection membership is product-scoped rather than variant-scoped.” And it works as documented for single-mechanism collections — we see null for members of classic/PRODUCTS-source collections.
But in a mixed collection (one CollectionConditionsSource with targetType: VARIANTS + one with targetType: PRODUCTS), a member admitted whole-product via the PRODUCTS source (manual selection with variantIds: null) returns an empty connection ([]) instead of the documented null — indistinguishable from “this product has zero variants in the collection”, which is the opposite of the truth (all of its variants are effectively in).
Repro (dev store, 2026-07):
- Collection with source A =
VARIANTS+ avariantPricecondition, source B =PRODUCTSwith a whole-product manual selection of product P. collection.productslists P as a member
P.variantsInCollection(collectionId:)→{ nodes: [] }
(docs say this case should be null)P.variantsInCollectionCount(collectionId:)→null— so the count field and the list field return different sentinels for the same state (and the count field’s docs don’t mention the null case at all).
Happy to share the store/collection IDs privately. Two asks: fix variantsInCollection to return the documented null for product-scoped members of mixed collections, and document the null behavior on variantsInCollectionCount too.
For anyone building on these fields in the meantime: treat both null and [] as “membership may be product-scoped — don’t interpret as zero variants” unless you’ve verified the collection has no PRODUCTS-target sources.
Hi Daniel, looking into these and will followup shortly.
Keep me posted Diana.
One more from the same migration, filed separately since it’s a general products/update issue rather than collections-specific: assigning variant images fires products/update with a stale product-level updated_at (frozen across four webhooks) while variants[].updated_at is fresh — which silently breaks the recommended “ignore older-or-equal updated_at” sync pattern. Full repro with timestamps: Products/update fires with a stale product-level updated_at for variant image assignment (variants[].updated_at is fresh) — silently breaks timestamp-gated sync
Mentioning it here because variant-scoped collections make variant-level freshness load-bearing: our scoped variant data went stale exactly this way while validating the new model.
Hey @Diana_Shopify could you clarify whether it is possible to query the collection status of a variant in Liquid, and if so, how?
The current documentation does not appear to include any information about this.
Thank you in advance!
Hi Robin, can you tell us more about what you’re trying to achieve?
Noted and flagged to the appropriate team.
Hey, sure I can provide a bit more context about what we’re trying to achieve.
Our app, FeeBee, applies fees or surcharges to orders. Currently, merchants can select a collection, and all products in that collection will have a fee applied.
We also display a banner on the product detail page, such as:
This product requires a $XX fee.
With the new Collections API, merchants can add individual product variants to a collection. We can support this at the Shopify Functions level, so the fee calculation itself should remain accurate.
The issue is on the storefront. For example, suppose a product has two variants, but only one of them belongs to the collection and requires a fee. As far as we understand, Liquid does not provide a way to determine whether the currently selected variant belongs to that collection. As a result, the banner would be shown for the entire product, including the variant that does not require a fee.
The banner is only one example. We also run other storefront logic that needs to determine whether the current product or selected variant is subject to a fee. To do that correctly, we need a way to resolve collection membership at the variant level in Liquid.
@Diana_Shopify will app-owned sources remain forever after the app owning it was uninstalled?
Deleting it would have strong consequence for the stores, I want to make sure they remain forever, at no conditions after the app was uninstalled.
Unless I missed something, it seems that Shopify silently went GA for the new UI
Seeing the same here @Soufiane_Ghzal (in the US-west region): dev stores and real stores have the new UI, yet there’s no changelog (dev or merchant-facing) nor any help manual doc updates… As a result, Sidekiq is also still serving old info
Thanks! Looks like this post was backdated, as it wasn’t included in the RSS feed on the claimed published date (July 16th). Odd that there are still no alerts or notifications or callouts in the Admin UI for such a big change.
I do see the help doc updates now, thankfully
there doesn’t seem to be a way to bulk extract all the variants from a collection efficiently. whilst we can use the collection query filter on productVariants, bulk queries are limited to 5 connections only which means each bulk query can only look up 5 collections, which is kind of pointless.
using the collections object, we can list products, but not variants - the product.variantsInCollection object requires us to specify the collection id as well (and only works for collections which are solely based on variants and not mixed), which in turn will exceed the 5 connection limit as well.
the collections object should have a variants property which lists all the variants in the collection too