Product family and revision
The configurable system, its stable identity, lifecycle state and effective product-model revision.
A saved project can state exactly which product definition it used.
Product architecture guide
One product record. Every customer and operational output.
A product configurator data model gives every family, dimension, option, rule and component a stable meaning. It keeps the product your customer sees in 3D connected to pricing, quotes, saved projects and the systems that receive the approved configuration.
Clear definition
The model beneath the configurator interface.
A product configurator data model describes the complete solution space in structured terms: product families, characteristics, option groups, allowed values, dimensions, components, rules, revisions and mappings. It also defines how one accepted customer configuration is identified, saved and reproduced.
The visual interface is one view of that model. The price calculation, quote, CRM record, ecommerce cart, configured order and optional bill of materials are other views. They can live in different systems, but they must agree on identifiers, product revision, selected values, units and configuration revision.
The data model is not a list of dropdowns. It is the contract that preserves product meaning when labels, languages, prices, rules, interfaces and connected systems change.
Interactive configuration record
Change the product. Keep its meaning connected.
This simplified pergola record shows the difference between customer-facing labels, the stable saved configuration and the fields a downstream system may receive. The identifiers are illustrative.
Valid product state
Bioclimatic pergola
Saved project · Revision 3
4.2 m
What the configurator stores
Structured configuration state
{
"configurationId": "cfg_7X4P2",
"configurationRevision": 3,
"product": {
"familyId": "PERG-BIO",
"modelRevision": "2026.08",
"label": "Bioclimatic pergola"
},
"selections": {
"mounting": {
"id": "MOUNT-WALL",
"label": "Wall-mounted"
},
"width": {
"value": 4.2,
"unit": "m"
},
"roof": {
"id": "ROOF-LOUV-MOTOR",
"label": "Motorized louvered roof"
},
"finish": {
"id": "FIN-ANTHRACITE",
"label": "Anthracite"
},
"sideScreen": {
"id": "SIDE-SCREEN-ZIP",
"selected": true
}
},
"validation": {
"state": "valid",
"ruleRevision": "rules-18",
"derived": [
"WALL-CONNECTION-SET"
]
},
"context": {
"market": "EU",
"locale": "en-IE",
"currency": "EUR",
"priceList": "DEALER-EU-2026-08"
}
}Core layers
Six parts of a connected product model.
Option groups and characteristics
Named decisions such as dimensions, mounting, roof, finish and accessories, each with a data type and allowed values.
Labels can change or translate without changing the stored meaning.
Rules and validation state
Dependencies, exclusions, ranges, derived values, warnings and the rule revision that accepted the configuration.
The system can explain why a choice was allowed, changed, reviewed or stopped.
3D and visual mapping
The node, material, visibility, dimension, animation or camera behavior driven by each accepted field.
The 3D scene displays the same product state that is saved and priced.
Commercial context
Price-list identity, account, market, currency, date, quantity, tax and approval context—separate from product meaning.
The same valid product can receive the correct commercial result for each audience.
Output and system mappings
Quote lines, product codes, CRM fields, cart payloads, configured-order data and optional BOM component mappings.
Every receiving system gets stable identifiers rather than trying to parse display text.
Identity and revisions
Give every meaning a durable identity.
One identifier should answer one question. This keeps product meaning separate from translations, interface labels and downstream document numbers.
Product family ID
Identifies the configurable system, not a customer-facing page title.
Model revision
Identifies the effective catalogue and rule structure used to create the state.
Characteristic ID
Identifies a decision such as width, mounting or finish independently of its label.
Value or component ID
Identifies the selected value, prepared variant or physical component mapping.
Configuration ID
Identifies the saved project state across sessions and connected systems.
Configuration revision
Identifies each accepted change without overwriting an earlier quote or approval.
Price result ID
Connects a calculated commercial result to its inputs and effective price context.
Output or order ID
Connects the configuration revision to the generated document or downstream record.
Variants and made-to-order products
A variant selector is not the whole configuration model.
Prepared variant
A known combination with its own SKU or product identity. Useful for stocked and frequently sold states.
Runtime configuration
A structured state assembled from dimensions, modules, options and rules. Useful for made-to-order products.
Matched result
A runtime state may match a prepared variant or continue as a configured order with characteristic values.
Design decision: do not create millions of meaningless SKUs only because the interface can generate millions of combinations. Define which states are prepared variants, which are configured records and what the receiving system expects.
Source of truth
Connected does not mean stored in one database.
A connected configurator can read from and write to several systems. The requirement is one authoritative owner for each field, stable mappings and visible failure handling.
DomainShould ownShould not become
Product catalogue or PIM
Families, stable product and option IDs, descriptions, lifecycle and market availability.
Runtime camera state or customer-project status.
Configuration model
Characteristics, allowed values, dependencies, exclusions, dimensions, derived state and rule versions.
Customer credit status or final accounting documents.
3D asset model
Geometry, materials, nodes, animation, camera presets and mapping to stable configuration fields.
The authoritative commercial price or translated product identity.
ERP, pricing or CPQ
Price lists, formulas, accounts, discounts, tax, approvals and configured commercial result where agreed.
Unversioned visual labels as a substitute for product identifiers.
CRM or project system
Customer, opportunity, owner, stage, activity and follow-up state.
The only copy of the product model or engineering rules.
ERP or production system
Accepted order, component, routing, production and fulfilment records where included.
A guessed configuration reconstructed from a PDF description.
Languages and markets
Translate labels. Preserve product meaning.
A multilingual configurator should not create a separate technical model for every language. It should render market-aware content around shared stable product IDs.
Language-neutral
Product, characteristic, value and component IDs; units stored explicitly; configuration and revision identity.
Market-aware
Availability, defaults, regulatory copy, price context, currency, tax and commercial documents.
Translatable
Product names, option labels, guidance, validation messages, quote content and customer communications.
Test completely
Configuration, rules, price, quote and destination records in every priority language and market—not only navigation labels.
Acceptance tests
Prove the record survives the real lifecycle.
Rename and translate
Rename an option and render it in another language. The stored IDs, price mapping and reopened project remain unchanged.
Save and resume
Save a valid project, close the session and reopen it. Every choice, derived value, visual state and revision is reproducible.
Revise after quote
Change one price-relevant field after issuing a quote. A new configuration and quote revision is created without rewriting history.
Change the rule model
Open a project created under an older rule revision. The system follows the agreed remain, review or migrate policy.
Send downstream
Create the target CRM, cart, ERP or BOM record from structured fields and verify identifiers, units, quantities and revision context.
Recover from failure
Reject or time out a destination call. The configuration remains intact and the operator sees an actionable delivery state.
Search-facing product data
Operational truth and SEO markup serve different jobs.
Product and ProductGroup structured data can help search engines understand visible products and prepared variants. It does not replace the operational model needed for rules, arbitrary dimensions, saved revisions, pricing context or production mappings.
Publish what the page represents
Use eligible Product or ProductGroup markup for visible product facts and prepared variants with unique IDs, canonical URLs and compliant offers where applicable.
Keep the richer system record
Store characteristic values, rules, visual mappings, configuration revisions, price context and downstream identity in the governed application model.
Primary references
Reference models for variants, characteristics and connected product data.
SAP: Variant Configuration
Official documentation describing configurable product structures using characteristics, configuration profiles and object dependencies.
SAP: Advanced Variant Configuration
Official reference for single- and multi-level configuration models, integrated product data and simulation including configurable BOMs.
Google: Product variant structured data
Official guidance for search-facing ProductGroup and Product variant markup, unique IDs and variant grouping. This is a publishing layer, not an operational configurator model.
Khronos: glTF
Official resources for efficient real-time 3D asset delivery. A visual asset format still needs explicit mapping to the governed product state.
Data-model FAQ
Detailed answers for product owners, IT and operations.
Continue your research
Connect the data model to rules, systems and delivery.
Modular product configurator
Model module instances, typed ports, slots, assembly relationships, derived parts and output mappings with durable identities.
Product configurator vs digital twin
Separate reusable product models, configured instances, physical assets and operational twin state with stable lifecycle identity.
Product rules engine
Define dependencies, exclusions, dimensional validation, derived values and rule versioning.
Product pricing engine
Use stable configuration IDs and commercial context to create traceable live-price results and quote revisions.
Configurator BOM generation
Map stable selections and derived values to exact component identities, quantities, revisions and operational destinations.
Configurator security and privacy
Classify records, enforce object and tenant boundaries, minimize browser exposure and test the complete data lifecycle.
3D asset pipeline
Bind stable product, component and finish IDs to nodes, materials, modules, transforms and governed asset revisions.
Product configurator integrations
Turn source ownership and configuration identity into reliable CRM, ERP and ecommerce contracts.
Product configurator PIM integration
Map product families, variants, attributes, translations, media and publication revisions to executable configuration.
Requirements checklist
Write testable data, rule, 3D, pricing, revision and output requirements for vendors.
Implementation guide
Prepare the catalogue, owners, assets, prices, journeys and evidence required for launch.
Maintenance and governance
Control catalogue changes, publishing permissions, saved projects and historical meaning.
Product configurator glossary
Align definitions for characteristics, variants, configuration identity, BOM, PIM, ERP and CPQ.
Bring one representative catalogue.
We will map its identities, characteristics, rules, visual states, price inputs and required operational outputs into one reviewable model.