My variants share a connector/part with other products — how do I stop overselling the shared component?

Shopify tracks inventory per variant, not per shared part — here's why products built from common components (connectors, bases, hardware) oversell, and how to model it correctly.

inventoryvariantsbundlesbill-of-materials

What's going on

Say you sell modular furniture, or any product line where several finished items share a physical part — a connector bracket, a base, a specific hardware kit. Each finished product has its own variant in Shopify, and each variant has its own inventory count. But the actual limiting factor isn't any one variant, it's how many of the shared part you have in stock. If you have 40 connectors and they get used by six different product variants, selling 15 units of variant A should reduce what variants B through F can sell too — but Shopify has no idea variant A's sale touched a shared resource at all.

The result: variants show available stock based on their own (often made-up or manually-guessed) numbers, customers order combinations that are actually impossible to fulfill because the shared part ran out, and the merchant finds out only when they go to pack the order.

This isn't a bug or a setting you're missing — Shopify's inventory model is intentionally simple: one quantity, per variant, per location. It was built for products that are independent SKUs, not for products assembled from a shared parts bin. Anything involving shared components, kitting, or a bill of materials sits outside what the core platform models, which is exactly why a small ecosystem of apps exists to fill that gap.

Why it happens

Shopify's inventory ledger is deliberately flat: every variant at every location gets one "available" number that you (or an app) set directly, and every sale decrements that one number. There is no concept in the core platform of one inventory item being referenced by, or shared between, multiple products or variants.

Shopify Bundles, the platform's own answer to composite products, does add a form of component-aware inventory — but it's scoped to a bundle product built from whole component products consumed 1:1. It doesn't cover partial consumption, many-to-many sharing across unrelated products, or components that get combined based on customer-chosen options, which is exactly the shape of the problem when the shared item is a raw material or sub-assembly rather than a discrete finished product.

5 ways to fix it

1

Track the bottleneck component as the SKU that gates availability

If one shared part (a specific connector, bracket, or bracket color) is genuinely the scarce resource, stop tracking inventory on every finished variant and instead track quantity only on the limiting component's own "product" (unpublished, not for sale). Use Shopify Flow's inventory trigger and adjustment action to mirror that count down to every finished variant that depends on it whenever an order comes in containing them. It is not real-time multi-directional sync, but for a small number of shared parts it keeps storefront availability honest without paying for a full BOM system.

2

Use Shopify's native Bundles app where the shared part is itself a sellable component

Shopify's free Bundles app (built by Shopify, managed in the Bundles item under Products) lets you build a bundle product from existing component products and it automatically decrements each component's own inventory when the bundle sells, and reflects a component's stockout as the bundle's stockout. It works well when your shared piece (e.g., a connector or base) is modeled as its own product with its own inventory. It does not handle cases where the same physical unit of a component is split fractionally across variants with different options, or where the relationship isn't a clean 1:1 bundle.

3

Model it explicitly with a bill-of-materials / kitting app

For anything beyond one or two shared parts, dedicated inventory or light-manufacturing apps (Katana, Cin7, Genie, Stocky-style kitting tools, and several Shopify App Store BOM/kitting apps) let you define components and consumption rules, then push accurate available-to-sell counts back to each Shopify variant automatically. This is the right tool once you have multiple shared components feeding multiple finished products, since spreadsheets or Flow workarounds stop scaling past a handful of SKUs.

4

Reserve safety stock and rely on backorder policies as a stopgap

If you can't build true component tracking yet, set the finished variants' inventory policy to a conservative fixed number below your actual component count (a manual buffer) and set "continue selling when out of stock" to off, accepting some lost sales in exchange for not overselling. This isn't accurate, but it's a zero-build stopgap while you evaluate the options above.

5

Talk to a developer about a custom reservation layer

If your shared-component structure is complex (many-to-many, partial consumption, multiple warehouses), a custom build using Shopify's Inventory API, metafields for component definitions, and a webhook-driven reservation service is sometimes the only way to get it exactly right. This is a real development project, not a quick app install, so it's worth scoping with a Shopify developer before committing.

Bottom line

Shopify's inventory system is fundamentally built to track one countable quantity per variant per location — it has no native concept of a shared part consumed by multiple finished products or variants. The closest built-in tool, Shopify Bundles, only closes the gap when your shared piece is a clean, wholly-consumed component of a fixed bundle; anything more tangled (partial consumption, many-to-many relationships, configurable combinations) needs either a Flow-based workaround, a dedicated BOM/kitting app, or custom development. Start with the cheapest option that matches your actual complexity rather than assuming you need a full manufacturing system on day one.

Still Stuck?

Browse the rest of the problem library, run a free storefront scan to catch issues like this automatically, or email us and we'll work out a custom solution for it.