Product Configurator Rules: Prevent Invalid Color and Component Choices

Define product configurator rules around combinations you can support, then recheck the selected configuration before building or selling it. A color swatch, component toggle and attractive preview are not enough: the system needs to know which choices require or exclude other choices.

Start with one product family. Record the source revision, independent option groups and the owner of each rule. Keep physical alternatives separate from viewing conditions: a metal base is a product choice; a close-up camera is not.

Translate the catalog into explicit constraints

A useful rule names both its trigger and its consequence. “Some fabrics need a different base” is not executable. “When upholstery is outdoor fabric, base must be outdoor-coated” is testable. Confirm the underlying catalog decision with the product owner before implementing it.

Competitor platforms also distinguish configurable catalog data from player presentation; Threekit’s item-variant documentation illustrates catalog variants and their player identifiers.¹ For your own implementation, define the business meaning before adopting a vendor’s vocabulary.

Do not expand every theoretical combination

Six fabrics, four bases and three arm choices create 72 theoretical selections. That is a counting example, not a requirement to render or store 72 complete models. Resolve the requested choice, validate it, compute its identity and build the necessary derivatives.

Keep a small regression set: a valid baseline, every rule’s failing case, boundary combinations and a previously released configuration. Add a test whenever a customer finds a combination the catalog cannot fulfill. Rules can interact, so passing each rule in isolation is not the whole acceptance test.

Keep price and stock outside visual assumptions

An invalid geometric combination should fail even when every part is in stock. A valid configuration can still be unavailable because inventory changed. Price may depend on region, account, quantity or date. Those are separate server decisions, not conclusions the viewer should infer from visible geometry.

In Rendora’s current option library, material choices and existing component nodes can be compiled into a configured GLB, with requires/excludes checks repeated on the server for workspace builds. Keep commercial pricing and inventory confirmation in the authoritative sales system.

Review rule changes as product revisions

If an old fabric-and-frame pairing is withdrawn, do not silently rewrite a published customer configuration. Preserve its source and rule revision. Decide whether it remains viewable, whether new builds are blocked, and what replacement is offered. The change record should identify affected configurations, not just the edited rule name.

Use the rule test worksheet to record allowed and blocked selections. Combine it with the configurator-versus-viewer comparison when scoping a purchase.

Questions before launch

Should impossible options disappear?

Sometimes. If disabling a choice helps explain the constraint, show the reason and a valid next choice. Avoid silently changing a customer’s configuration.

Can a browser check be the final authority?

Use it for immediate feedback. The server must recheck permissions and configuration rules before durable build or release operations.

Is every component alternative a separate model file?

Not necessarily. Alternatives may be explicit nodes within one master. Name the node set and preserve the original source so selections are reproducible.

References

1. Threekit, Item variants, checked October 26, 2026.