Shopify’s 2026-07 API release changes how apps read and write collection logic. A collection no longer has to be described by one legacy rule set. It can now be backed by one or more sources, with typed inclusion conditions, exclusion conditions, manual selections and sub-collections.
That sounds like developer plumbing, but it affects a practical merchant question: when an app changes collection rules, what exactly is it changing, and can your team still see every collection it has created?
Shopify explains the change in its developer changelog for the new collection model and APIs. The short version is that stores and apps moving to API version 2026-07 get a richer way to model collection membership. Stores and apps that stay on older API versions may not see collections that use the new features, because the old rule-set shape cannot represent them.
What changed in Shopify collections
In older collection logic, apps commonly worked with Collection.ruleSet. Shopify has now deprecated that field in favour of Collection.sources. A source can include products through typed conditions, include manual selections, exclude products through exclusion conditions, or pull membership from sub-collections.
The new model also lets each source target products or variants. That matters for larger catalogues where a product may have many variants and only some of those variants belong in a particular merchandising group. Kahunam has covered the operational pressure behind this in Shopify Now Supports 2,048 Product Variants: What This Means for Your Store.
For Shopify Functions, the ProductVariant type gains two collection membership fields: inAnyCollection(ids: [ID!]!) and inCollections(ids: [ID!]!). Those fields let a Function check whether the variant itself belongs to a collection. The existing product-level membership fields still work at product level.
Why merchants should care before apps rewrite rules
The risk is not that Shopify has broken collections. Shopify says these changes are non-breaking, and deprecated members remain queryable in 2026-07 so apps can migrate gradually.
The risk is visibility and control. If an app starts creating collections with multiple sources, exclusion conditions or shareable app sources, another app still using an older API version may not be able to list or manage those collections correctly. Shopify says earlier API versions filter collections using the new features out of collection-returning queries because the old shape cannot describe them.
That creates a simple audit point for merchants: before an app rewrites collection logic, confirm which API version it uses and whether your reporting, search, merchandising and discount tools can read the resulting collections.
Questions to ask app vendors and developers
Start with API version support. Ask whether the app reads and writes collections through the 2026-07 GraphQL Admin API, and whether it has migrated from ruleSet to sources. If the answer is no, ask what happens when another app creates a collection using the new model.
Then ask how the app handles exclusions. The new source model supports typed exclusion conditions, including collection-based exclusions. That can be useful for merchandising, but it also means exclusion rules can define a collection by what they leave out as well as what they include. Your team should be able to inspect that logic without needing a developer to decode it.
Ask whether the app uses shareable collection sources. Shopify’s changelog says a shareable source can link to many collections, and the calling app owns it. Only the owning app can update or delete its shareable sources, and deleting one automatically detaches it from every collection that links to it. That ownership model is useful, but it makes vendor offboarding and app replacement worth planning.
For stores with large variant sets, ask whether the app checks product-level or variant-level membership. A discount, delivery rule or merchandising decision may behave differently if it treats a whole product as being in a collection rather than checking the specific variant in the basket.
A practical migration checklist
List every app that creates, edits or reads Shopify collections. Include merchandising apps, filter apps, discount apps, fulfilment logic, search tools and any custom admin utilities. The important test is whether the app depends on collection membership, not whether its main category is collections.
Check the API version each integration uses. Apps that need full visibility of new-model collections should move to 2026-07 or later. Apps that only read legacy ruleSet data need a migration plan before new collection sources become part of day-to-day operations.
Create a small test collection before changing live merchandising rules. Use a product condition, a manual selection and an exclusion condition if your app supports them. Then check whether every dependent tool can find the collection, show its membership accurately and avoid overwriting the new source structure.
Document ownership for app-created sources. If a source belongs to one app and many collections rely on it, record what happens if your team disables, replaces or removes that app. This is a housekeeping task, but it prevents a future collection clean-up from turning into guesswork.
The takeaway
Shopify’s new collection model gives developers a better way to express modern merchandising rules. Merchants don’t need to learn every GraphQL type, but they should ask sharper questions before allowing apps to rewrite collection logic. The key checks are API version, source visibility, exclusion handling, shareable-source ownership and variant-level membership.
Author
