A configuration is a saved walk through one Configuration Template for one real-world order, quote, or build slot. It’s the output of a Configurator run: the selections, material assignments, and resolved parts list that turn the template’s possibility space into a concrete bill of materials for that order.Open a template in Configurator to see the configurations walked from it.
The configuration itself carries identity only — a name and description. Its purpose is to group all the revisions for one order under one identifier you recognize (“Heavy-Duty Quote”, “Job 12345”).
Every state-bearing fact — selections, material assignments, resolved parts list, per-revision notes — lives on a child revision, numbered #1, #2, and so on.
The configuration’s active state is its latest (highest-numbered) revision. The latest revision can be edited in place and deleted; earlier revisions are read-only, and the revision chain is the audit trail.
Each selection records which options were chosen for one option class, plus optional notes. Cardinality follows the class’s Selection type: Select one must land exactly one option, Select at least one at least one, Select many zero or more.
Attributes — the pinned values, using the same condition types as BOM variant conditions (true/false, text, number, range). Prefer fully-pinned values — a range on a revision usually means a decision is unresolved.
Source — where the value came from: an ERP part reference, “customer order PDF line 3”, a mapping-file row
Notes — why the decision was made: justification and edge cases
Source, Notes, and Revision notes carry three different kinds of provenance — where the value came from, why the decision was made, and what changed in this revision. Nothing blocks a revision on an empty Source, but it is an audit-trail gap: treat it like an unverified assumption, since an assignment no one can trace can’t be evaluated at reconfiguration time.
The Configurator computes a flat parts list from the current selections and material assignments — every material reachable given the option choices, with its pinned attribute values. This is the concrete parts list the configuration produces for the order.
A revision moves through four phases as it’s walked: pending → selecting_options → assigning_materials → completed. The phase is derived from the revision’s current state — it is not something you set by hand. See Configurator for the full phase model.
Open a template in Configurator and choose New configuration. Pick how to start:
Manual — enter a Name and Create. You start from an empty revision and pick options yourself, one decision at a time, then fill each material’s attributes with a Source and Notes.
With Dexter — optionally choose an Order document (order PDF, ERP export) and add Instructions, then Send to Dexter. Dexter walks the option tree one confirmed decision at a time, then pins material attributes, source-batched against your grounded inputs. The order document is cited on each assignment’s Source rather than attached to the configuration itself.
When every required decision is made and every selected material has values, Commit revision locks the current revision and creates a copy of it as the new latest revision.
Open the configuration to land on its latest revision, and switch revisions from the revision picker. The latest revision opens in the workspace, showing:
The selections made per option class
The material assignments with their Source, Notes, and pinned attribute values
Earlier revisions open read-only as their resolved parts list — each part with its attributes, entity, and quantity — so you can see the result at that point in time. Compare shows the parts added, removed, or changed in quantity between each pair of consecutive revisions, alongside each revision’s notes. It doesn’t flag a change to a pinned attribute, such as a part number, on a part whose entity and quantity stayed the same, so open both revisions to check attribute values.
When a completed configuration needs to change — the customer revised the order, a sourced value turned out wrong, a template edit cascaded into the selection set — Revise the latest revision with the button beside the revision picker. Revise is available once the latest revision is complete with no errors, and offers two paths:
Manual — start a new revision based on the current one, add Revision notes, and Create revision. Then edit it yourself.
With Dexter — choose a Change document and/or describe the changes, then Send to Dexter. Dexter creates the new revision.
Either way, the new revision starts as a copy of the latest one. Keep every selection and assignment that isn’t changing, remove the entries that are, resolve any new stale entries or errors, then walk the open decisions to completed.To discard the latest revision — an abandoned reconfiguration, say — use Delete revision in the More actions menu. Only the latest revision can be deleted, and only when it isn’t the configuration’s only revision.
This is advisory, not a product rule: revising is always valid regardless of how much changes. But as a rule of thumb, if a reconfiguration would remove most of the entries, a fresh configuration under the same template is often a cleaner walk than carrying a nearly-empty revision forward.
A completed revision’s resolved parts list is the handoff point to whatever comes next:
Quotes and customer-facing documents — Export from the configuration’s overflow menu to download an Excel file: Export current revision exports the latest revision’s parts list, and Export all revisions exports one sheet per revision. Each sheet has Material, Quantity, and Entity ID columns; pinned attribute values aren’t included, so when an attribute identifies the ordered variant, add it before sending the file on.
Planning demand — configurations do not auto-create demand orders. Feeding a revision into a scenario is a distinct step: either manual (add the demand order against the SKU) or pipeline-mediated (a pipeline that reads the resolved materials and writes the demand).
Simulation — simulation models reference entities through model nodes, not revisions. If a configuration’s material set needs to drive a simulation input, wire it through a pipeline.
Configurations are per-template. A configuration can’t move between templates; reconfiguring against a different template means a fresh configuration under that template.
Only the latest revision is editable. Earlier revisions are read-only; to change one, revise the latest revision.
Write Revision notes as the delta. The revision number already handles ordering; the notes should say what changed.
Template edits are global. Edits made mid-run — by Dexter or with the in-app add actions — change the template for every other configuration built on it.
When Dexter drives, stale entries are dropped automatically; errors with exactly one valid repair are applied directly, and anything ambiguous becomes a decision for you through the ask-confirm loop.
Nothing downstream is automatic. Completing a revision hands you a parts list; it does not commit demand, allocate supply, or schedule production.
