Configuration Templates

​

Overview

A configuration template captures the possibility space for a configurable product — the option tree and the entity references a configurator session walks through. Materials don’t live in a separate library; each one references an entity in the shared entity registry. A template is authored once per product line and reused across every customer order the line serves. A concrete walk through the template is saved as a revision under a Configuration — the Configuration is the container for one customer order, and each revision is a numbered snapshot of the selections and material assignments made against the template. The Configurator drives the walk. Configurator in the sidebar opens the list of templates; create one with New template.

​

Structure

Every template is a tree with two kinds of node at every level — materials (parts that are always included) and option classes (decision points that branch). A material and an option class are distinct kinds of nodes. At the top level a template carries:

​

Materials

​

Option Classes

Option classes appear in the app as decisions; add one with Add category.

​

Options

Each option carries an ID, an Option name, its own materials, and its own option classes. Nesting is recursive: picking an option can expose nested option classes that were invisible until then — choosing diesel-engine reveals a turbo-configuration class beneath it. Nested classes only become reachable once their containing option is selected.

​

Instructions

Instructions on materials and option classes are prose read at decision time. Use them for:

• Cross-tree rules — “If chassis-size: heavy is selected, the tow-package class must include class-iv-hitch.”
• Sourcing rules — “Pin voltage from the customer’s electrical spec; default to the entity’s standard voltage if absent.”
• Decision criteria — “Choose aluminum for corrosive environments; steel otherwise.”

​

Change Log

The change log is chronological. Dexter appends a one-line entry when it makes a structural change to an existing template mid-run — splitting a static material into a Select one class to accommodate a new quantity, or adding an option because a customer order didn’t fit. It stays empty when authoring the initial template, and edits made directly in the app don’t add entries.

​

Creating a Template

New template asks how you’d like to start:

​

Manual

Best for a new product line where you already know the decision shape.

1. Make sure the entities the template will reference exist — every entity that appears on a material must exist first.
2. Choose Manual, then give the template a Name, an optional Description, and the Entity it produces. Create template saves an empty template.
3. Build the tree from a configuration against the template: Add category for each decision, Add option for its choices, and Add material for the parts an option brings in. These edits write straight to the template.
4. Ask Dexter to fill instructions on any class or material with non-obvious sourcing rules, cross-tree constraints, or decision criteria.

​

With Dexter

Best when the shape of the product already lives in an ERP config table, a spec sheet, or an order document.

1. Choose With Dexter and pick the file as the Configuration source document.
2. Optionally give a Name; leave it blank to let Dexter infer a name from the document.
3. Send to Dexter. Dexter reads the document in your current chat and builds the template. It names materials from the description column, derives each entity from the description rather than the part number, and carries quantities across — part numbers stay out of the template so they can be pinned per revision.
4. Review the generated template — option-class structure and instructions almost always need a pass, because source tables rarely encode decision semantics.

​

Editing a Template

Templates are editable throughout their life, in two contexts:

• Between runs — edit freely. Existing configurations reference materials by material ID, so don’t change those keys.
• Mid-run — allowed when a customer order doesn’t fit the current option set. Dexter gates the change through an ask-confirm turn and logs it in the change log; the in-app Add custom, Add category, Add option, and Add material actions apply immediately. See Mid-Run Template Edits.

​

Authoring Rules and Prerequisites

• Material IDs are stable. Revisions pin to them; changing a material ID breaks the link for every prior revision that referenced it. Add a new material and phase the old one out instead.
• Give every referenced entity a part-number attribute. Dexter works to this convention: when it builds a template it checks that each referenced entity declares a text part-number attribute, and adds one to the entity definition if it’s missing. Text typing accommodates alphanumeric numbers (like PN-1001-A) and lets a not-yet-numbered part be pinned to a placeholder value until the real number lands. Nothing enforces the attribute, so templates you build manually won’t flag an entity that lacks it.
• Part numbers do not live on template materials. They belong on revisions as pinned attribute values.
• Quantity is fixed at the template level. If the same part appears in two contexts with different quantities, model two separate materials with different IDs. If quantity itself is a customer decision, model it as a Select one option class where each option carries a differently-quantified material.
• Entities before templates. A material can only reference an entity that already exists; a material whose entity can’t be found shows as Unknown in the configuration tree.

​

Limits and Caveats

• Cross-class rules in instructions are not machine-enforced; selections that violate them are not rejected automatically.
• Deep option trees (4+ levels) are supported but hard to walk and hard to reconfigure — keep nesting shallow when the product allows it.
• An option ID must be unique within its own option class; an option class ID must be unique across the whole template, since selections address classes by ID. A class in one option can technically share an ID with a class in a different option, but conflating them makes the audit trail hard to read.
• Changing a material ID after any configuration has been built is the single most common way to break existing revisions.