> ## Documentation Index
> Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# How to set up variants on a listing

> Offer one listing in several forms — defining options, what each variant draws from in inventory, and per-variant pricing.

<Card title="Open in TWICE Admin" icon="external-link" href="https://admin.twicecommerce.com/catalog/listings" horizontal>
  catalog/listings
</Card>

Variants let one listing be offered in several forms — sizes, colours, lengths — so a customer picks on the listing page rather than hunting through a catalog of near-identical entries.

The part that decides whether variants are worth it is not the options. It is what sits behind each one: a variant that draws from the same pool as every other is presentation, and a variant that draws from its own stock is inventory. Both are legitimate, and they are configured in different places.

## Prerequisites

<Warning>
  **Required permission:** listing manage rights. All four system roles hold them.
</Warning>

<Info>
  **Decide first whether your variants differ in stock, in price, or only in name.**

  * **Name only** — options are for the customer's benefit and nothing behind them changes.
  * **Stock** — each variant draws from different units, and needs variant-specific rules.
  * **Price** — a large size costs more, and needs variant pricing.

  Most listings need the first. Setting up the other two when you did not need them is maintenance you will carry for the life of the listing.
</Info>

## The Walkthrough

<Steps>
  <Step title="Define the options">
    On the listing's **Variants** tab, add **Variant options** — *add options like size and colour*.

    Each option has an **Option name** (the admin's placeholder is *Color*) and a set of values. Add values with **Add option**; each option needs at least one, and blank names or values are rejected.

    Every combination of values becomes a variant, and the tab shows a running **Total variants** count. Watch it — options multiply. Three sizes and four colours is twelve variants, and each one is a thing that can be individually priced, individually stocked, and individually wrong.
  </Step>

  <Step title="Keep the list under control">
    **List of variants** shows what you have generated. Before going further, ask whether every combination is real: if you do not stock a red one in extra-large, that variant exists in the catalog and will disappoint someone.

    Fewer options with more values is almost always easier to run than more options.
  </Step>

  <Step title="Point each variant at its stock — if they differ">
    By default every variant draws from the listing's base rule on the **Fulfilment** tab. That is right when the variants are presentational.

    When they genuinely draw from different units — a size medium is not a size large — use **Variant specific rules** on the Fulfilment tab to *set additional stock rules for each variant of this listing*. Each variant gets its own conditions and its own quantity, layered on the base rule.

    Match on an attribute the units actually carry. If your stock does not record size, no variant rule can find it, and the fix is on the stock rather than in the rule.

    Read more: [Listing inventory rules](/docs/guides/catalog/listing-inventory-rules)
  </Step>

  <Step title="Set per-variant pricing — if they differ">
    Pricing on the Variants tab distinguishes **Base** from **Variant pricing**. Base is what every variant costs unless it says otherwise; variant pricing overrides it for one.

    Only set variant pricing where the price genuinely differs. A listing where all twelve variants carry the same explicitly-set price is twelve things to update the next time prices move.
  </Step>

  <Step title="Check stock availability per variant">
    The **Stock Availability** view on the Variants tab shows what is actually behind each one.

    A variant with nothing behind it is bookable-looking and unbookable, which is the specific failure this view exists to catch. Check it before publishing rather than after.
  </Step>

  <Step title="Mark a recommended variant if one leads">
    **Add recommended variant** marks one as **Recommended**. Useful when one option is the common choice and you would rather a customer landed on it than picked at random.
  </Step>
</Steps>

## How do I know it worked?

* **The listing page offers the options**, and picking a combination selects a variant.
* **Stock Availability shows units behind every variant you intend to sell** — not just the first.
* **A variant with different pricing shows its own price**, and the others show the base.
* **Booking a specific variant holds a unit from that variant's pool**, which is the check that proves variant rules work at all.

## Troubleshooting / Common Pitfalls

<AccordionGroup>
  <Accordion title="One variant cannot be booked while the others can">
    **Cause:** that variant's rule matches no stock. On a listing with variant-specific rules each variant resolves separately, so one empty pool takes out one variant rather than the whole listing.

    **What to do:** open **Stock Availability** and find the variant with nothing behind it. Either the units for it do not exist, or they exist and do not carry the attribute the rule matches on.
  </Accordion>

  <Accordion title="Every variant shows the same stock">
    **Expected if you have not set variant-specific rules.** All variants fall back to the listing's base rule, so they share one pool — the options are presentational.

    **What to do:** if they should draw separately, add variant rules on the Fulfilment tab. If they genuinely are presentational, nothing is wrong.
  </Accordion>

  <Accordion title="I have far more variants than I meant to">
    **Cause:** options multiply. Every combination is generated, whether or not you stock it.

    **What to do:** reduce the number of *options* rather than values — dropping one option with three values removes two thirds of the combinations. If only some combinations are real, consider separate listings instead; variants are for a grid you genuinely fill.
  </Accordion>

  <Accordion title="&#x22;Variant name already exists&#x22;">
    **Cause:** two values would produce the same variant, or a value is duplicated within an option.

    **What to do:** check the option's values for near-duplicates — trailing spaces and case differences are the usual cause and are hard to spot in a list.
  </Accordion>

  <Accordion title="Variant pricing is not being applied">
    **Cause:** the variant is falling back to **Base** because no variant price is set for it, or the price is set on a different variant than the one being booked.

    **What to do:** check the pricing against the specific combination the customer chose. On a large grid it is easy to price *Large / Red* and believe you priced every large.
  </Accordion>

  <Accordion title="Should this be variants or separate listings?">
    **Variants** when it is one thing a customer chooses between on one page, and the grid is mostly filled.

    **Separate listings** when the options need different descriptions, different images, different publishing, or when most combinations do not exist. Also when only some are sold at some locations — publishing is per listing, not per variant.
  </Accordion>
</AccordionGroup>

## Next Steps

<CardGroup cols={2}>
  <Card title="Create and publish a listing" icon="plus" href="/docs/guides/catalog/create-and-publish-a-listing">
    The listing the variants sit on.
  </Card>

  <Card title="Listing Variants tab" icon="grip" href="/docs/catalog/listings/variants">
    The tab reference, field by field.
  </Card>

  <Card title="Variants" icon="sitemap" href="/docs/concepts/catalog/variants">
    What a variant is in the data model.
  </Card>

  <Card title="Listing inventory rules" icon="table-list" href="/docs/guides/catalog/listing-inventory-rules">
    The base rule the variant rules layer on, and how to check what it matches.
  </Card>
</CardGroup>
