Product Model Setup Guide

Product Models in Wheelhouse: Setup Guide

Product Models are how Wheelhouse understands what you actually sold. Part numbers describe how a product is built and priced; models describe what it is in the way your business talks about it: a product family, a product, a size. Once models are set up, every order line is tagged with exactly one model, and demand reporting can roll up cleanly by family, by product, or by size, without double-counting and without anyone decoding part numbers.

This guide walks through the full setup, in the order you should do it:

Design the model tree
Create the tree in Wheelhouse
Assign models to items
Tell each configurator which selection decides the model
Verify the setup

Everything here is done with the Configurator Admin role (or full admin).

How the pieces fit together

Piece	Where it lives	What it does
Model tree	Admin, under Items, in Item Models	The hierarchy of families, products, and sizes you report by
Model field	On each Item record	Links an item to one node of the tree
Model Items list	On each Configurator record	Names which configured selections are allowed to decide the model for an order
Order tagging	Automatic	When an order is configured, Wheelhouse finds the first selection that is on the Model Items list and stamps that selection's model on the order line

The key idea: a configured product is built from dozens of selections, and many of them could carry a model. The Model Items list is the decision maker. It tells Wheelhouse "of everything in this configuration, THIS is the selection that says what the customer bought."

Step 1: Design the tree on paper first

Draw the hierarchy the way you want demand reports to read. A good test: imagine the monthly demand review, and write down the row labels you want to see.

Example for a bicycle manufacturer:

Bikes
├── Summit (mountain)
│   ├── Summit 17in
│   ├── Summit 19in
│   └── Summit 21in
├── Metro (commuter)
│   ├── Metro Standard
│   └── Metro Folding 16 - 20in
└── Parts

Guidelines that make the tree work well:

The bottom level (the leaves) is where demand lands. Make the leaves the level you plan at. If you buy materials and schedule production by size, the leaves should be sizes. Parent rows exist for structure and roll-ups.
One deciding level per branch. Each finished unit should be counted at exactly one node. If size matters for a product, count it at the size level, not at both the product and size levels.
A size-range node is fine when one physical item covers a range (like an adjustable frame). Model the range as its own leaf, as in "Metro Folding 16 - 20in" above.
Include a catch-all like "Parts" for spare parts and accessory orders, so that volume is visible without cluttering the product families.

Step 2: Create the tree in Wheelhouse

Go to Admin, open the Items section, and select Item Models.
Create the top-level nodes first (the families). Each model has a Name and an optional Parent Model.
Create each child by setting its Parent Model to the node above it. The list displays as a tree, so you can confirm the structure as you build.
Use the Sequence field to control display order within a level, if you want something other than alphabetical.

Names can be edited later without breaking anything, and a model can be moved under a different parent; reports pick up the new structure immediately.

Step 3: Assign models to items

Open each relevant Item record and set its Model field. The dropdown shows the full path (for example "Bikes > Summit > Summit 19in") so it is always clear where in the tree the item sits.

Which items get a model?

Situation	Item to assign
Configured product where a size option determines the variant	Each size option item (assign "Summit 17in" to the 17in frame option, and so on)
Configured product where the base selection determines the variant	Each base item (assign "Metro Folding 16 - 20in" to the adjustable folding base)
Standard product sold directly, no configurator	The item itself
Spare parts sold through a parts configurator	The parts configurator's product item, assigned to your "Parts" model

Assign models at one level per finished unit. Components, hardware, and other options that do not define what the product is should be left without a model.

Step 4: Tell the configurator which selection decides

This is the step people miss, and nothing resolves without it.

Go to Admin and open Configurators.
Open the configurator for the product.
In the Model Items list, add every selection that is allowed to determine the model for an order. The picker only offers items that already have a Model assigned (Step 3 must come first).

When a customer order is configured, Wheelhouse walks the configuration in the order the selections appear and stops at the first selection that is on this list. That selection's Model becomes the order line's model.

Two rules follow directly from "first match wins":

Cover every path. Every configuration a customer can build should include exactly one selection from the list. If a product has three base styles and seven size options, and size is what you report by, all the size options belong on the list, for every base style, including regional or special-edition variants.
List only the deciding level. If you list both a general base item and its size options, the base is encountered first and always wins, and all demand lands on the general model instead of the sizes. If you want size-level reporting, the base items should not be on the list.

For simple products where the base selection itself is the variant (one base per size, or a size-range base), listing the bases is exactly right.

How Wheelhouse applies the model

The model is stamped on the order line when the order is configured, at quoting. It then travels with the order automatically: quote to sale to invoice. Reports at every stage see the same model.
If a configuration is edited and saved again, the model is re-resolved at that time, so a size change updates the model.
Changes are not retroactive. Editing an item's Model or the Model Items list affects orders configured from that point on. Existing order lines keep the tag they were given. Plan to have models in place before you need the history, and treat the first weeks of data accordingly.
Ordinary (non-configured) order lines are tagged with the item's own Model, if it has one.

Step 5: Verify the setup

Work through this list once per product:

Model Items list is complete. Open the configurator and confirm every base or size variant that customers can choose appears in the list, and that nothing above the deciding level is listed.
Every listed item resolves. Each entry in the list should show a real model. A listed item whose Model field is empty resolves to nothing, and orders that hit it get no model tag.
Place a test quote per variant. Configure one of each major variant and confirm the demand reports count it under the intended model.
Watch the catch-alls. If model-based reports show volume at a parent level where you expected sizes, a general item is winning the resolution; revisit rule two in Step 4.

Maintenance

New size or variant item: two actions, always together. Assign its Model on the item, and add it to the configurator's Model Items list. Make this part of your new-product checklist.
New product family: add the tree nodes first, then items, then the Model Items list, in that order.
Renaming or reorganizing the tree: safe at any time; reports follow the tree live.
Retiring a product: leave its model in place. History reported against it stays meaningful.

Set up this way, the model tree becomes the single spine for demand reporting: every unit sold lands in exactly one leaf, leaves add up to products, products add up to families, and the numbers can be trusted at every level.