Model a configurator option as an actual WooCommerce product when that choice has its own stock, price, tax, SKU or order handling. Store simple preferences as metadata, but add physical or separately managed components as their own cart lines. This keeps the catalogue and order chain authoritative.
A configurator may visually look like a single product while the actual configuration consists of several items. If every choice disappears into one text field, stock cannot be reserved per component and the warehouse cannot see what to pick. Conversely, turning every colour or text label into a product makes the catalogue unnecessarily complex. The boundary follows the operational meaning.
Use a decision rule for each option
| Does the option have… | Model as | Example |
|---|---|---|
| Its own SKU and stock | Separate product line | Mounting kit or extra panel |
| Its own tax or shipping behaviour | Separate product line | Installation service or heavy component |
| Only a customer preference | Validated metadata | Handle position |
| Free-form personalisation text | Bounded metadata | Short engraving |
| A choice that determines the main variant | Product variation | Standard size and base colour |
Also ask who manages the option. If operations must be able to change its price or stock in WooCommerce without changing the configurator, that points towards an actual product. If the choice only helps display production instructions and is never sold separately, metadata may be more logical.
Keep the customer-facing view as one whole
Separate cart lines do not have to look like disconnected, confusing products. Link them to a main line, group them visually and make clear that they belong to the configuration. Prevent customers from removing a required component separately or changing its quantity independently when that is technically not allowed.
Calculate totals using the current products' WooCommerce prices. Do not copy an old price from the browser. Check on the server that a selected product is actually permitted in this configurator and the requested quantity is within the limits. For more on the order chain that follows, see reliably integrating an online store and ERP.
Test discount and tax rules against the chosen structure. A coupon for the main product need not automatically apply to an installation service; a free add-on may still need to remain an actual zero-price line so the warehouse can see it. Have the responsible specialists determine the commercial and tax setup, and ensure the technology consistently applies their chosen rules.
Fictional example: a modular workbench
Workshop supplier Staal & Vorm sells a workbench with optional drawers, wheels and an engraved nameplate. The drawer cabinet and wheel set have their own SKUs, stock and picking locations. They are therefore added as linked product lines. The engraving text remains bounded metadata attached to the nameplate.
In the basket, customers see one configuration block containing the main product and components. When they increase the number of workbenches from one to two, the required wheel sets scale with them. A one-off engraving instruction is not simply doubled; the interface asks whether both nameplates should have the same text. In the warehouse, all actual items appear as separate picking lines.
When transferred to the ERP, SKUs and quantities remain recognisable, while the configuration group can be included as a relationship. An integration such as Yindle Connect can translate that final structure into the back-end systems in a controlled way.
Staal & Vorm also stores a readable configuration summary on the order. That summary helps customer service and the customer, but does not replace structured SKUs. A product label changed later can otherwise make a historical order difficult to understand. Keep both stable identification and the label displayed at the time of ordering.
Data model checklist
- For each choice, determine whether stock, price, tax or fulfilment is independent.
- Use stable product and variation IDs, rather than visible labels alone.
- Only permit add-on products approved in advance.
- Revalidate quantities and availability on the server.
- Preserve the relationship between the main product and components in both cart and order.
- Define removal, quantity changes and session recovery for the group as a whole.
- Show customers and the warehouse an understandable configuration summary.
- Test a price change, an out-of-stock component and a removed option.
Create a small domain model on paper before drawing the interface. This reveals which choices are actually products, variants, services or instructions. If standard plugins cannot reliably support this model, the discussion of custom software or standard software helps you choose the right boundary.
Include returns and cancellations in that outline, even if they fall outside the initial configurator screens. If one component is returned, it must remain clear which main configuration it belonged to and whether the other components are still usable. Design that relationship before orders are created; reconstructing it from descriptions afterwards is prone to errors.
Have Yindle develop the data model for your product configurator.
The described model is available in Yindle Kit Configurator. Also read how to build a configurator with real products before connecting options to your catalogue.