What is the difference between product rules and pricing rules?

Product rules define what can be configured. Pricing rules calculate the commercial result for an accepted product state, account, market, quantity, date and other inputs. They are connected but should remain distinguishable. A choice can be valid yet differently priced by market; a price formula should not be used to hide an otherwise invalid engineering combination.

What product rule types should a configurator support?

Typical types include allowed values, defaults, required choices, dependencies, exclusions, substitutions, minimums, maximums, increments, quantities, derived values, conditional visibility, warnings, review thresholds and hard stops. The required set depends on the product. Buyers should test observable examples instead of accepting a vendor's generic statement that it supports business rules.

How are dependencies and exclusions different?

A dependency says that one state requires or activates another—for example, an option requires a compatible control. An exclusion says that two states cannot coexist. Dependencies may be one-way, so the reverse relationship should not be assumed. Both need an explicit trigger, action, scope, message, recovery path and test case.

Can a rules engine handle parametric dimensions?

Yes, when the product model defines the relevant ranges, increments and dimensional relationships. The engine can validate entered dimensions, derive module or component quantities and decide whether a boundary requires review. The 3D model, price calculation and output mapping must consume the same accepted values rather than maintain separate interpretations.

Should an invalid configuration be blocked or automatically corrected?

Use the least surprising action that preserves product intent. A hard stop is appropriate when no valid output can exist. A warning or specialist-review state may fit a resolvable exception. An automatic correction can be helpful when the change is predictable and clearly disclosed. Silent replacement is risky because the customer may believe a different product was saved or quoted.

How should conflicting product rules be resolved?

Define execution order and precedence explicitly. A practical model separates stable product constraints from market availability, role permissions, defaults, derived calculations and commercial review. When two actions can change the same field, document which wins, why it wins and how the user is informed. Add a regression case for the collision rather than relying on rule order by accident.

Can non-technical administrators edit configurator rules?

Some governed changes can be administrator-managed: labels, translations, availability, defaults or approved catalogue values. Structural geometry, engineering limits, complex formulas and production mappings often need a specialist. The right boundary depends on risk. Editing permission, review, test evidence and publishing permission should be separate decisions.

How should product rules be documented?

Give every rule a stable ID, plain-language intent, condition, action, scope, priority, user message, recovery path, owner, effective version and test cases. Use stable product and option IDs rather than labels. Link the rule to its authoritative source and to the expected price, 3D or downstream effect where applicable.

How do rules connect to a bill of materials?

The accepted product state can drive component mappings, quantities, dimensions and substitutions when those outputs are in scope. Keep the distinction between a sales summary, configured order, sales BOM and production-ready manufacturing BOM. Operations must approve the exact identifiers, hierarchy, units, tolerances and revision behavior before an output is described as production ready.

How should a configurator rules engine be tested?

Test common, minimum, maximum, just-outside, dependency, exclusion, conflicting-rule, historical-project and downstream-output cases. Each case needs known inputs and an expected allowed state, message, automatic action, price input and required output. Re-run the relevant pack whenever the product, rule, price, geometry or integration contract changes.

What happens to saved configurations when rules change?

Record the rule and product revision used by the saved configuration. Define whether an older project remains valid, is re-evaluated with an explanation, needs review or must migrate. Issued quotes and accepted orders should remain traceable to the product and rule context that created them rather than silently inheriting a new meaning.

How should rule-engine vendors be compared?

Give vendors the same representative product and test pack. Ask them to demonstrate dependencies, exclusions, dimensional boundaries, derived values, messages, rule conflicts, saved-project versioning, role and market scope, price inputs and downstream mapping. Compare observable evidence, maintainability and ownership—not the number of rule names in a feature list.

Can Configurix model rules for more than pergolas?

Yes. Configurix is designed for configurable and made-to-order product workflows across product families such as pergolas, verandas, doors, windows, fences, gates, garden rooms, carports, outdoor kitchens, furniture, HVAC and industrial equipment. The actual rule model, visuals, pricing and outputs are scoped from each catalogue and accepted source data.

Product logic guide

Product rules that keep every configuration valid.

A product configurator rules engine turns catalogue knowledge into guided choices, valid dimensions, compatible options and explainable review states—then passes the same accepted product state to 3D, pricing, quotes and operational outputs.

Test the example Model your product rules

Clear definition

The logic between a catalogue and a valid product.

A catalogue lists what exists. A rules engine determines which combination of those products, dimensions, components and options can exist together for a specific market, role or project. It evaluates the current configuration whenever a relevant input changes and returns a controlled result.

That result may allow the choice, require another component, calculate a derived value, replace an option, display a warning, request specialist review or stop an invalid state. The important part is consistency: the saved configuration must mean the same thing to the 3D scene, live-price calculation, quote, order and optional bill of materials.

Rules are not the interface. A disabled control, filter or wizard step is only the visible effect. The real product logic needs stable identifiers, ownership, messages, versioning and tests behind it.

Interactive rule evaluator

Change one choice. See every affected rule.

This simplified bioclimatic-pergola example demonstrates dependencies, exclusions, dimensional checks and review routing. The values are illustrative product logic—not engineering limits for a real system.

Width4.2 m

2.0 m7.5 m

Mounting

Roof system

Same side elevation

Zip screenSliding glass

Valid

Valid configuration

The current demo state passes its dependency, exclusion and dimensional checks.

Width is inside the illustrative system range.

Selected side elements do not conflict.

Derived state

Motor and control · requiredWall connection set · required

Rule types

Six behaviors a serious rules engine must explain.

Allowed values and defaults

Define which choices exist for a product, market, role or channel and which safe starting value appears first.

A dealer catalogue starts with its assigned product series and default finish.

Required choices and dependencies

Require one field, component or service when another selection or condition is present.

Selecting motorized louvers also requires a compatible control package.

Exclusions and substitutions

Prevent incompatible combinations or replace an option with the approved alternative while keeping the reason visible.

A selected side element can exclude a conflicting element on the same elevation.

Dimensions, ranges and increments

Validate minimums, maximums, step sizes, quantities, clearances and dimensional relationships.

Width must use an accepted increment and remain inside the chosen system range.

Derived values and quantities

Calculate values the user should not enter manually, such as module count, material area or component quantity.

The selected span and system determine a derived support or module count.

Warnings, review and hard stops

Separate a valid configuration, a state that needs specialist review and a combination that cannot proceed.

A boundary case remains saved but cannot become an approved quote until reviewed.

Connected architecture

Do not force every decision into one rule layer.

Clean ownership makes errors easier to find. Each layer answers a different question while reading the same configuration identity and stable product data.

Catalogue

What exists?

Families, components, option groups, identifiers, lifecycle and market availability.

Configuration rules

What is allowed?

Requirements, exclusions, dependencies, limits, derived values and review states.

Geometry

What should change visually?

Dimensions, visibility, material assignment, position, repetition and animation.

Pricing

What should it cost?

Price lists, formulas, quantities, accounts, markets, discounts, tax and rounding.

Output mapping

What should leave the system?

Quote lines, product codes, BOM or order components, drawings and integration fields.

Rule record

Make every rule reviewable before it becomes executable.

A spreadsheet cell, remembered exception or unlabeled script is difficult to test and dangerous to change. Use a shared rule record that product, engineering, commercial and implementation owners can read.

Stable rule ID

A durable identifier that does not change when customer-facing wording is renamed or translated.

Plain-language intent

The product or commercial reason the rule exists, written so a reviewer can challenge it.

Condition

The product state, audience, date, market or value that activates the rule.

Action

Allow, require, hide, exclude, substitute, calculate, warn, request review or stop.

Priority and scope

Where the rule applies and how it resolves a collision with defaults, market rules or another action.

Message and recovery

What the user sees and the specific choice that returns the product to an accepted state.

Owner and evidence

The accountable source, effective version and normal, boundary and invalid test cases.

Across configurable products

Different catalogues. The same disciplined rule model.

Bioclimatic pergola

Inputs: Mounting, width, projection, roof, finish, screens, glazing, lighting and heating.
Rule behavior: Validate dimensional ranges and option compatibility; derive structural modules and required controls from the accepted product model.
Connected result: Valid specification, live-price inputs, quote lines and optional component or project data.

Entrance door

Inputs: Opening, handing, frame, panel, glazing, hardware, finish and security package.
Rule behavior: Keep hardware, glazing, dimensions and regulatory options compatible with the selected door system and market.
Connected result: Door identity, dimensions, selected components, price inputs and customer proposal.

Modular furniture

Inputs: Module sizes, arrangement, finish, doors, drawers, shelves, handles and accessories.
Rule behavior: Limit unsupported spans, keep fittings compatible and calculate repeated parts from the layout.
Connected result: Configured layout, commercial lines and an agreed component or order structure.

Industrial or HVAC system

Inputs: Capacity, dimensions, environment, connection, module, finish and service options.
Rule behavior: Use technical inputs to narrow compatible modules, require supporting components and route exceptions to engineering review.
Connected result: Validated selection, calculation inputs, quote and approved technical handoff fields.

Execution and conflicts

A predictable order prevents rule collisions.

Load context

Resolve product revision, market, channel, account, role and effective date before presenting choices.

Apply availability and permissions

Remove choices the current audience cannot use without changing their stable product identity.

Apply defaults and user input

Create a complete current state while preserving explicit choices that remain valid.

Evaluate constraints and derived values

Run requirements, exclusions, limits, substitutions and calculations until the state is stable.

Return one explained result

Expose accepted, review or invalid status plus messages and recovery actions to every connected layer.

Conflict rule: if two actions can write to the same field, define precedence and add a named collision test. Execution order should be a governed design decision, not an accidental side effect.

Acceptance and regression

Test the edge of the allowed solution space.

A polished common journey proves very little about rule accuracy. Keep a permanent pack that tests the values and combinations most likely to expose contradictions.

Normal

A common configuration follows the expected route without unnecessary warnings or automatic changes.

Minimum

The smallest accepted value remains selectable, visible, priced and represented in every required output.

Maximum

The largest accepted value behaves exactly as defined, including derived components and performance.

Just outside

A value immediately beyond an accepted limit produces the intended stop, correction or review state.

Dependency

Selecting the trigger creates the required choice, message or component without leaving stale data.

Conflict

Two incompatible choices cannot silently coexist; the user can see why and how to recover.

Historical

A saved project created under an older rule version is reopened, explained and handled according to policy.

Downstream

The same accepted state reaches price, quote, BOM or integration output using stable identifiers.

Versioning and ownership

Rules change. Historical meaning must not.

Each saved configuration, quote and accepted order should remain traceable to the product and rule revision that produced it. When a rule changes, decide which new, saved, quoted and ordered projects it affects before publication.

Assign an owner for the rule source, an owner for implementation and an approver for the resulting product behavior. Separate permission to edit from permission to publish. Re-run the relevant rule, price, visual and output cases, then monitor the first live use and retain a correction path.

Read the maintenance and governance guide

Primary technical references

Reference models for conditional and composable validation.

These sources illustrate established ways to describe conditional requirements, rule composition, inclusion, exclusion and execution order. Configurix scopes the actual implementation from the customer's catalogue and accepted architecture.

JSON Schema: conditional validation

A primary technical reference for conditional requirements and if/then/else validation patterns. It is an external reference model, not a statement about Configurix internals.

JSON Schema: schema composition

Explains AND, OR, exclusive-OR and NOT composition—useful concepts when documenting overlapping validation criteria.

SAP CPQ: product rules and execution order

An official example of configuration rules limiting a product to valid states and why execution order matters when actions affect the same attributes.

SAP CPQ: configurable products

An official example of configurable attributes governed by inclusion, exclusion and bundling rules.

Rules-engine FAQ

Detailed answers for product owners and buyers.

A product configurator rules engine evaluates a structured product state against catalogue and business logic. It decides which values are allowed, required, incompatible, derived or subject to review. A useful engine does more than disable controls: it keeps a valid saved state, explains invalid choices, supplies consistent inputs to pricing and downstream outputs, and records the rule version that produced the result.

Continue your research

Bring one representative product.

We will map its options, dimensions, dependencies, exclusions, price inputs and required outputs into a reviewable configuration model.

Book a product-rules review