Skip to content

Models

36 identical MacBooks, 72 iPads: a model (e.g. “MacBook Air 13” M4”) describes once what they all share — name, category and field values like manufacturer or RAM. Each unit stays its own item with its own label, location and history. Change something on the model, and the units follow automatically.

  1. Under “Models” → “New model”: set the name and category — the category is required, because it determines which fields the units carry. Optionally a photo.

  2. The detail page bundles everything: the shared data, the field defaults and the list of units — the card title keeps count (“36 units”).

    A model's detail page with field defaults and units

Name and category live on the model: all units are named after the model (distinguishable by code and label) and can’t be renamed or recategorized on the unit. Rename the model, and all units are renamed in one go — with a single activity entry instead of dozens.

The model carries default values for its category’s fields — say, manufacturer “Apple”, model number and RAM. New units start with these values, and a changed default takes effect live on all units that haven’t overridden the value themselves.

On the unit, the origin of every value is visible:

  • “From model”: the value comes from the model and follows it on changes.
  • “Overridden”: the unit has its own value — model changes leave it untouched. “Reset to model default” restores the inheritance.
  • “Adopt as model default” goes the other way: the unit’s value becomes the new default for all non-overridden units.

A unit with "From model" and "Overridden" markers

Manufacturer and model number are perfectly normal custom fields — they can be filtered, exported and managed per category like any other field.

Per field, the model can restrict the possible values — the MacBook model only comes in the conditions “New” and “Good”, say. “Restrict values” under the field default sets the list; on the unit the field then becomes a select instead of free input. Already-captured values outside the list are kept and marked “(not allowed)”; the import also warns when a row would set a value that isn’t allowed.

Field defaults with restricted values on the model

“Create instance” on the model detail page (or “New item” with a model chosen) opens the capture form without a name field — the name comes from the model, the fields are prefilled with the defaults. What’s left is only the unit-specific part: serial number, location. “Create another” adds device after device.

Capture form for a new unit with prefilled defaults

Every unit captured this way gets its own label: a scan then opens that exact device — not the model. Manufacturer barcodes on the packaging lead to no model; such a barcode can be attached to a unit, though, and finds it afterwards like any other label (mobile app).