WooCommerce product dependencies let you decide whether a customer may purchase a product only after meeting a defined condition. This can mean buying a prerequisite product earlier, adding another item to the current cart, holding a particular user role, reaching a lifetime-spend condition, or having an active subscription or membership. The rules are configured at product level through the separate WooCommerce Product Dependencies extension, not through WooCommerce Core alone.
This distinction matters when a store sells upgrades, refills, related offers, bundles or products available only to an existing customer group. A recommendation or upsell encourages another purchase; a dependency rule can control whether the target product may be purchased and how the requirement is presented. The correct setup depends on whether you need a completed previous purchase, a same-order prerequisite, or an account-based condition. It also needs validation across the actual cart, checkout and product integrations used by the store.
What WooCommerce Product Dependencies Solve
A product dependency attaches an eligibility rule to the product being protected. In the product editor, the store owner can define conditions based on prerequisite products, categories, tags or attributes. The extension also documents conditions based on current cart contents, past orders, active subscriptions, active memberships, customer lifetime spend and user roles.
This allows a store to distinguish between a customer who has already purchased a required product and one who has only expressed interest in it. It can also distinguish between a customer who may buy the target product in the same order and one who must qualify through account data. These are different business rules and should not be treated as interchangeable.
Dependency rules versus recommendations
An ordinary recommendation or upsell does not necessarily affect eligibility. The customer can usually ignore it and continue purchasing. A dependency is different because the configured outcome can refuse the purchase with an explanation, remove the buy button, hide the product from the store, or add missing prerequisite items to the cart when that option is supported.
The chosen outcome determines the customer experience. A visible product with a clear explanation may be appropriate when customers need to understand the requirement. Hiding a product creates a different catalog experience and should be assessed against internal links, promotions, SEO plans and support workflows. No dependency setup should be assumed to cover every custom sales route without testing.
How to Require a Previous Product Purchase
To require another product first, open the product that should be protected in the WooCommerce product editor and use its Dependencies tab. Add a rule for the relevant prerequisite. Depending on the documented condition types, this may be a specific product or variation, category, tag or attribute. Then select the qualification source that matches the intended customer journey.
If the customer must have genuinely bought the prerequisite before purchasing the target product, choose a past-order condition. This is the important distinction between purchase-history gating and a same-cart requirement. A past-order condition does not pass simply because the prerequisite has been added to the current cart. After defining the condition, select the documented behavior for an unmet dependency and test the result with the customer-facing message that the store will display.
Past order versus current cart
Use a past-order requirement when the target product is available only to customers with a qualifying previous order. The relevant evidence is the customer’s purchase history, not the contents of the current cart. This supports a genuine “buy this first, then access the next product” flow.
Use a current-cart requirement when both products may be purchased together. In that case, the prerequisite can be present in the same order, so the customer does not need a completed earlier purchase. The extension also documents a choice where the prerequisite may qualify from the cart or from past purchase history. Before publishing the rule, check which interpretation matches the store’s intended process and explain the missing condition clearly.
Reviewing rules across the catalog
The product editor is the primary place to configure a dependency for an individual target product. After several products have rules, a separate WooCommerce Dependencies screen can be used to review dependencies across the catalog. This review is useful for checking whether the rules still reflect the current product structure and customer journey.
Review the catalog-level setup after changing prerequisite products, categories, tags or attributes. Also verify that the customer-facing outcome remains understandable. A technically valid rule can still create confusion if the product is hidden, the purchase button disappears, or the explanation does not tell the customer whether a previous purchase or a current-cart item is required.
Purchase History, Current Cart and Customer-Account Conditions
WooCommerce product dependencies can evaluate several kinds of customer data. Past-order rules look for qualifying purchase history. Current-cart rules inspect what is being purchased now. Account-based rules use information connected with the customer account, including user roles and lifetime spend. Separate conditions can also use active subscriptions or active memberships when the required extensions are present.
These conditions answer different questions. Purchase history asks whether the customer has bought something before. A role condition asks whether the account has a selected role. Lifetime spend asks whether the account meets the configured spending condition. Subscription and membership conditions ask whether the relevant account status is active. Combining them requires care because every assigned rule must pass.
When login status changes the result
Guests cannot satisfy a user-role condition because they have no user roles. They also count as zero lifetime spend, so a lifetime-spend condition does not pass for a guest. As a result, account-based restrictions require the customer to log in before those conditions can be evaluated as satisfied.
Test the same target product as a guest and as a logged-in customer. Also test an authenticated account with the required role or purchase history separately from an account without it. This helps distinguish a rule configuration issue from an expected result caused by missing customer account data. Purchase-history gating and role-based gating should remain separate in the testing plan because they use different qualification information.
Subscription and membership prerequisites
Subscription conditions require WooCommerce Subscriptions. Membership conditions require WooCommerce Memberships. Without the corresponding extension, the related condition types do not appear in Product Dependencies. Do not treat these conditions as automatically available in a standard WooCommerce installation.
For stores using subscription-based eligibility, confirm that the intended subscription status is available in the connected setup and test it with an authenticated customer. WooCommerce Subscriptions supports subscription products in simple, variable, bundle and composite product contexts, but the complete dependency and checkout combination still needs validation in the store’s own configuration.
Choosing the Right Rule Outcome
When a dependency is not satisfied, Product Dependencies documents several possible outcomes. The store may refuse the purchase with an explanation, remove the buy button, hide the product from the store, or add missing prerequisite items to the cart when possible. These choices are not equivalent.
Refusing the purchase with an explanation keeps the requirement visible and can tell the customer what is missing. Removing the buy button presents a stricter product-page experience. Hiding the product changes catalog visibility, so it should be checked against direct links, promotions, SEO plans and support processes. Adding a prerequisite to the cart can assist the customer when that behavior is supported, but it should not be confused with satisfying a past-order condition.
Combining multiple requirements
When multiple rules are assigned to one product, every rule must pass. The rules therefore work with AND logic. A customer who satisfies one condition but fails another is still blocked according to the configured outcome.
The order of the rules also affects the message: the first failing rule in the configured order determines what the customer sees. Arrange rules deliberately and use the least-surprising explanation possible. Identify whether the missing condition is a previous purchase, a cart item, an account role, spending condition, subscription or membership. Then test the order of failure rather than assuming that customers will see every unmet condition at once.
Bundles, Composite Products and Checkout Blocks
Product Dependencies documents rule checks on Product Bundles, Composite Products and Mix and Match containers. It also documents checks across product pages, catalog-related flows, cart and checkout, including classic and block-based cart and checkout, as well as reorders. This means dependency behavior should be assessed in the product contexts the store actually uses.
Bundle compatibility must still be assessed separately. Product Bundles can group simple, variable and subscription products, but its documentation identifies integration-specific limitations for some combinations using block-based Checkout. Therefore, documented dependency checks do not justify a blanket assumption that every bundle, connected extension and checkout implementation will behave identically.
Why block-based checkout needs separate validation
There are two related questions to verify. First, does Product Dependencies evaluate the rule in the relevant block-based cart or checkout flow? Its documentation states that dependency rules are checked in those flows. Second, does the complete Product Bundles integration behave as expected with the selected block configuration? Product Bundles documentation lists supported integrations and notes limitations for some integrations with block-based Checkout.
Test the exact bundle, prerequisite relationship, cart and checkout implementation, and connected extensions on staging. Include a customer who qualifies, one who does not qualify, and a case where the prerequisite is added to the same cart. Do not generalize a result from one bundle or one checkout flow to every other store configuration.
Testing and Troubleshooting Checklist
Run dependency testing on staging before enabling restrictions on a live store. The objective is not only to confirm that a rule blocks or permits a purchase, but also to verify that the customer sees the intended product, cart and checkout experience. Include the account states and purchase paths that are relevant to the configured conditions.
Check the product page and catalog behavior first. Then test direct product access, the cart, classic checkout, block-based checkout and reorders where those flows are used. If the store uses containers or connected extensions, include representative Product Bundles, Composite Products and Mix and Match scenarios. Review the exact failure outcome in each case.
Minimum test matrix
- Customer identity: test a guest and a logged-in customer, including an account that should satisfy the condition and one that should not.
- Qualification source: test a completed prerequisite purchase separately from adding the prerequisite only to the current cart.
- Account conditions: test user-role and lifetime-spend rules with authentication, because guests have no roles and count as zero lifetime spend.
- Optional integrations: test subscription conditions only with WooCommerce Subscriptions active and membership conditions only with WooCommerce Memberships active.
- Purchase flows: check the product page, catalog visibility, direct access, cart, classic checkout, block-based checkout and reorders where applicable.
- Product containers: test the exact Product Bundles, Composite Products or Mix and Match configuration used by the store.
- Customer messaging: confirm that refusal, button removal, hiding or cart assistance produces the intended result and identifies the missing condition.
WooCommerce product dependency rules can support prerequisite products, purchase-history checks and customer-account conditions, but the result depends on the selected rule type, failure outcome, login status and connected integrations. The key distinction is whether the prerequisite must have been purchased previously or may be included in the current cart. Account-based conditions also require careful guest and logged-in testing.
Before publishing a restriction, validate the complete journey on staging, including bundles, reorders and the relevant checkout implementation. Treat compatibility as product- and integration-specific rather than universal, and do not assume that one tested route covers custom sales flows. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.