> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/product/using-peakcommerce/products-and-bundles/product-sets.md). # Product Sets A **Product Set** is a curated group of products you present together — the menu of plans and add-ons a customer chooses from in a storefront or a journey. Rather than tying products to a single flow, you assemble them once into a set and reuse that set wherever you sell. Product Sets are also the unit that **Offers** and **Audiences** target, so they're how you control *who* sees *which* products. Manage them under **Commerce → Product Sets**.
A Product Set detail page with its base products and add-ons, each showing classification, pricing tiers, charges, and commerce rules

A Product Set (Commerce → Product Sets) — the base products and add-ons in the set, each with its pricing tiers and commerce rules.

## What's in a set A set is organized into two groups: * **Base products** — the core plans a customer picks one of (for example a Starter and an Advanced tier). Each shows its classification, pricing tiers, and charges. * **Add-ons** — optional services layered on top of a base plan (priority support, advanced analytics, extra usage), often priced as a percentage of MRR or on usage. For each product in the set you can see its **classification**, **pricing tiers**, the underlying **charges**, and any **commerce rules** that apply — and the set carries a **status** of its own. ## How sets are used * **Offers** and **Audiences** target a Product Set to decide who is eligible for it and what pricing they get — so the same set can power different experiences for different customers. * A journey or storefront resolves a Product Set to render the available plans, instead of hard-coding products into the flow. This replaces the legacy journey-scoped "Categories" model. ## Per-item visibility Every item in a set has its own **Visibility** setting, so a single set can show a slightly different menu to different customers without you maintaining separate sets: * **Always shown** (the default) — the item appears for every customer the set is offered to. * **Only during an active trial** — the item appears in customer-facing plan pickers only while the customer is in a trial (see below for how "in a trial" is determined), and is hidden from paying customers. This is how you gate trial-specific choices — for example a free-trial plan that should be selectable while someone is evaluating, but shouldn't clutter (or tempt) the plan picker once they're paying. Two behaviors worth knowing: * **The customer's current plan is always shown**, regardless of its visibility setting — so the "you're on this plan" state renders correctly even after a trial-only plan's window has passed. * **"In a trial" is a catalog decision you make, not something inferred.** Each set item carries a **Free trial — converts to paid** toggle, right beside its Visibility setting. The trial-only gate shows trial-only items when the customer's **current plan matches an item you've flagged** as a genuine trial — so you define once, per item, what counts as a trial, and that single definition applies consistently across the [customer portal](/product/customer-self-service/subscription-management/customer-subscription-management.md), CSR tools, and journeys. Because nothing is guessed from billing-system structure, a scheduled plan change can't be mistaken for a trial, and a real trial is recognized even when its billing shape looks unremarkable. The same plan can be flagged as a trial in one set and left unflagged in another, since the flag lives on the set item, not the product. ### Free trial vs. free plan Beside it sits a second toggle, **Free plan — never charged**. Both look "free" to a customer, but they behave in opposite ways at checkout, so the toggles are labelled by what they *do*: | Toggle | What the customer pays | Signup | | --------------------------------- | -------------------------------------------------- | --------------------------------- | | **Free trial — converts to paid** | nothing now, your normal price when the trial ends | a payment method **is** collected | | **Free plan — never charged** | nothing, ever | no payment method is collected | A plan can be one or the other, not both — turning one on turns the other off. Leave **both** off for an ordinary paid plan, **and also for a promotion that happens to make a paid plan $0 for a while**: that customer still converts, so a card must be collected or there will be nothing to charge when the promotion ends. Journeys read these toggles — not the price — to decide whether to show a payment step, so a $0 price on its own never skips checkout. ## How each line is booked Each item in a set has two settings that decide how its line is booked when a journey places the order. They sit together on the item's card, **Order grouping** directly above **Effective Date Timing**. | Setting | Options | Default | What it does | | ------------------------- | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Order grouping** | **Default — grouped with other lines** · **Its own order line** | Default — grouped with other lines | **Its own order line** books the line as its own order action (an **Add Product**) within the same order and subscription. Takes effect only in journeys whose create-order action has [Honor order grouping](/product/journeys-and-pages/journey-steps/commerce-actions.md#honor-order-grouping) turned on; everywhere else the line is booked with the rest. | | **Effective Date Timing** | **Same as Order Date** · **Set Period (After Subscription Date)** — a number of **Days**, **Months**, or **Years** | Same as Order Date | When the line starts, counted from the order date. A set period (for example 30 days after a trial) defers that line's start. | On the item card: * A line set to **Its own order line** shows an **Its own order line** tag. * A line with a set period shows an **Activates +N** tag (for example **Activates +1 months**). Lines on the default for both settings show no tag, so the lines that behave differently stand out without opening them. **Adding products:** the **Add products** panel has its own **Order grouping** select. The value you pick there is applied to every plan added in that batch; change individual lines afterwards on their cards. **Bundles:** a bundle's face and each of its members are separate lines, and each has its own **Order grouping** and **Effective Date Timing**. A member does not inherit the face's values, so a bundle's free trial and its paid plan can start on different dates and be booked in different order actions. **No republish needed.** A journey reads the set when a customer starts checkout, so changes to these settings apply to every checkout started after you save. Checkouts already in progress keep the values they started with. For how the order is assembled from these settings, with a worked example, see [Guide: Booking a Line as Its Own Order Action](https://docs.peakcommerce.com/guides/feature-guides/billing-setup/guide-booking-a-line-as-its-own-order-action). ## Create and manage 1. Go to **Commerce → Product Sets** and open or create a set. 2. Add **base products** and **add-ons** from your [Product Catalog](/product/using-peakcommerce/products-and-bundles/products-overview.md). 3. Set the order and any commerce rules, then set the set's **status** to **Active**. ## Gotchas * **A set must be Active to resolve.** A storefront or journey pointed at a draft or inactive Product Set won't return products (it resolves to nothing) — activate the set before wiring it into a flow. * Products in a set still come from the catalog: a product's own status and provider link govern whether it can actually be sold. See [Managing Products](/product/using-peakcommerce/products-and-bundles/managing-products.md). ## Related * [Products Overview](/product/using-peakcommerce/products-and-bundles/products-overview.md) * [Managing Products](/product/using-peakcommerce/products-and-bundles/managing-products.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.peakcommerce.com/product/using-peakcommerce/products-and-bundles/product-sets.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.