Managing Configurable Furniture: A Product-Data and Commerce Guide
How to structure product data for configurable furniture: parent products, variants, dependencies, dimensions, pricing, availability and asset matching.

A sofa offered in three sizes, six fabrics and two arm styles has 36 theoretical combinations. The first job is to establish which of those combinations are genuinely sellable. Each valid variant then needs the right price, any dimensions that differ, and imagery that represents what is being sold.
In Furniture Connect, one possible structure would be separate products for each arm style, with size and fabric represented as the two native variant axes. That is an example, not an automatic modeling decision. The right structure has to be agreed for the range.
This guide explains the data structure behind configurable furniture, the decisions a catalog team must make and where each deeper question belongs.
Signs the structure is already breaking
A few symptoms show up long before anyone frames the problem as "our configurable data is unstructured." A salesperson has to recalculate a price because the exact fabric-and-size pairing isn't priced. A retailer rejects a feed because the image belongs to a different fabric.
Elsewhere, the dimensions describe a different frame size from the one being sold. Or a customer gets two answers about a discontinued fabric because "discontinued" and "out of stock" were never recorded as separate facts.
None of these look like a data-structure problem from the inside — they look like one-off mistakes, a bad quote, an unlucky feed rejection. They're worth tracking as a pattern rather than individually, because the same underlying cause — data recorded at the wrong level, or not recorded per-variant at all — tends to produce all four.
What makes a product "configurable"
Schema.org's ProductGroup type describes products that vary in defined ways such as size, color or material. That is a useful working model for furniture: one parent concept, such as a sofa range, with specific sellable variants beneath it.
The practical test is whether the variation is structured or improvised. If the valid size-and-fabric combinations are named, priced and available to quote, the range is configurable. If those options exist only in a PDF that a salesperson interprets each time, the range may still be configurable, but its ordering process remains manual and vulnerable to interpretation errors.
The shape underneath: parent, variant, SKU
Underneath every configurable model sits a hierarchy: a parent product, variants representing the specific combinations that are actually sellable, and a SKU for each one. The parent should group products that differ only in defined ways. It should not be used as a catch-all for an entire collection containing different furniture types.
The most common failure isn't missing data. It is data stored at the wrong level. A dimension that only applies to the large-frame variant gets stored on the parent and used for every size. A fabric withdrawn from one configuration remains visible across the whole range. Parent Products, SKUs and Variants: How Furniture Catalogs Should Be Structured explains where each fact belongs.
Furniture Connect can preview CSV and spreadsheet headers and help teams review field mappings before import. For flat product imports, an incoming SKU that matches an existing catalog product updates that product, changing only the fields included in the import. Configurable ranges need a separately agreed parent-and-variant structure: the bulk importer does not automatically turn spreadsheet rows into variant families.
Where dependencies enter the picture
Not every combination in a configurable range is valid. A given fabric might only be available on certain frame sizes; a particular arm style might not exist in the largest configuration. This is where configurable furniture data gets genuinely harder than "list every option and every value."
Furniture Connect does not currently provide a compatibility engine for requires-and-excludes rules. The valid combinations must be defined explicitly before they are imported, generated or quoted. How to Model Option Dependencies in Configurable Furniture sets out a practical way to record them.
Dimensions that move with the configuration
A finish change may leave a dining table's dimensions unchanged, while a different size or construction may change its length, width, height or clearance requirements. A sofa's clearance depth may also change with arm style.
In Furniture Connect's current Agent workflow, native dimensions are maintained on product records. Where configurations require different measurements, a supported approach is to create separate product records for the distinct sizes or constructions, with suitable finish or fabric variants beneath them. Do not assume that selecting a size option automatically changes the stored dimensions.
How to Store Dimensions That Change by Furniture Configuration covers how to separate shared measurements from configuration-specific ones and how to make inheritance explicit.
Pricing across the configuration matrix
Price may vary by size, fabric grade, finish or market. How to Manage Pricing Across Furniture Sizes, Fabrics and Finishes explains how to keep the approved commercial values attached to the correct variant and sales route.
Teams can use formulas to calculate values in eligible base-catalog fields, including suitable numeric attributes. These formulas are not a configuration-pricing engine and do not directly update native selling prices or dimensions. Approved commercial prices must be maintained against the appropriate sellable variants. Channel-specific content values do not, by themselves, provide market-specific pricing or commerce synchronization.
Availability means more than "in stock"
A configuration can have stock remaining and still be withdrawn from sale. It can also be offered but temporarily unavailable. Furniture Connect exposes separate lifecycle and stock statuses on variants, but those fields should not be read as live warehouse quantities, lead times or automatic withdrawal from external sales channels. Configuration Availability vs Stock Availability explains the operating distinction.
Matching the right asset to the right variant
A hero image, lifestyle shot, fabric swatch and finish swatch do different jobs. How to Match the Right Product Asset to Each Furniture Variant sets out the decision logic.
Furniture Connect can store variant-specific images and support reference-based image generation and editing. Images still need checking against the intended configuration before use; generating an image does not establish that the depicted combination is manufacturable or approved.
Naming and identifying variants
SKUs are internal identifiers you control; GTINs are standardized identifiers governed by GS1. Furniture SKU Naming Conventions for Configurable Ranges lays out a practical naming approach without confusing the two.
Measuring whether your configurable data is actually ready
Once the structure, dependencies, dimensions, pricing, availability and assets are in place, the next question is whether every sellable variant is ready. The Configurable Furniture Data Quality Checklist provides a binary check at variant level.
Where standard configuration ends and custom begins
Every configurable range has an edge: a fabric that is not approved, a size outside the engineered range or a construction change. Where Standard Configuration Ends and Custom Furniture Begins explains how to draw that line before the quote is built.
Where product-content infrastructure fits
Furniture Connect can hold product and variant data alongside related materials and imagery. Flat spreadsheet imports, parent-and-variant modeling, calculated attributes and native commercial fields are distinct parts of the workflow rather than one automatic conversion.
Its current native variant model supports up to two axes per product. More complex ranges need an agreed structure, which may use separate products, supporting attributes or documented order-time selections where appropriate. Supporting attributes and order notes do not become additional native variant axes, and they do not automatically enforce compatibility, calculate surcharges or maintain separate stock. Any option affecting the commercial item needs an explicitly agreed recording and quoting process.
Furniture Connect does not decide which combinations are valid. The team must establish that before creating records or imagery.
How the nine pieces fit together
The parent, variant and SKU structure comes first. Dependencies define what can be sold. Dimensions, prices and availability describe each valid variant. Assets show it accurately. Naming keeps it traceable. The checklist tests whether the range is ready, while the final guide defines which requests sit outside the standard catalog.
A step you can take this week
Pick the configurable range with the most sizes, materials and finishes. List the valid combinations, then check whether each one has an approved price, the right dimensions, a clear availability state and representative imagery. The missing cells are the work standing between the range and a reliable listing or quote.



