Product configuration rules engine: constraints explained

A product configuration rules engine is the part of a configurator that decides which combinations of options are valid, which options apply to this buyer at all, and what each choice costs. In Spokbee, three families of rules do that work: constraints block combinations that cannot be built, visibility rules hide parameters that do not apply, and pricing rules turn every selection into a price. A buyer, a sales rep or an AI agent can therefore only ever produce a configuration that engineering would sign off.

This explainer defines the term, lists the six constraint types Spokbee supports, shows how visibility and pricing rules fit with them, and walks through what a buyer sees when a rule fires.

What is a product configuration rules engine?

A product configuration rules engine evaluates a product's rules against the buyer's current selections every time a selection changes. It returns three answers: which option values are still allowed, which parameters should be visible, and what the configuration costs. It sits between the option list and the quote, and it is what makes a configurator more than a form.

In Spokbee the rules live with the product definition. Every configurator owns a schema, the schema defines parameters, and parameters carry constraints and pricing rules, as the core concepts documentation describes. Parameters are the choices a buyer makes, in seven types: select, radio, color, toggle, slider, number and text. Each parameter has an id, and that id is the variable name a rule refers to, so a constraint on width or a formula using height reads exactly like the engineer who wrote it meant it.

That is the difference from the old way of working. Before a rules engine, the rules lived in a spreadsheet with hidden columns, in a configuration guide nobody kept current, or in the head of an application engineer who checked every order by hand. A rules engine writes those rules down once, in a form the configurator can execute, and applies them to every configuration without a person in the loop.

Why are invalid configurations so expensive?

An invalid configuration costs money at every step it survives: a quote that has to be redone, an order that engineering rejects, or a product built to a specification that cannot work. The later it is caught, the more people it involves. A rules engine catches it at the first click, before it becomes anyone's problem.

The pressure to get this right is growing because buyers increasingly configure products on their own. In a Gartner survey of 632 B2B buyers, 61 percent said they prefer a rep-free buying experience overall (Gartner press release, June 2025, checked October 2026). When nobody from sales sits between the buyer and the order, the rules have to do the job the application engineer used to do.

Spokbee's customers show what that looks like in practice. Stor-Loc, which makes industrial tool storage, replaced manual calculations and 2D drawings with a Spokbee configurator and automated quoting. Routine quoting now takes half the time, and the automated workflows have significantly reduced errors in quoting and layouts, as the Stor-Loc customer story reports. Alba Racing, which sells custom wheels assembled from dozens of components, reported fewer production errors once customers could only build combinations the configurator allowed (how Alba Racing uses Spokbee).

What types of constraints does a rules engine need?

Spokbee supports six constraint types: requires, excludes, conditional range, arithmetic, count limit and combination rules. Requires and excludes express dependencies between two parameters. Conditional range and arithmetic handle dimensions and capacity. Count limit caps how many options of one kind a buyer can pick. Combination rules forbid or require exact combinations across three or more parameters at once.

The examples and logic come from the constraints documentation, checked October 2026. The same page gives the advice most teams need: start with requires and excludes, which cover about 80 percent of real-world constraint needs, and add arithmetic constraints only for products with dimensional or area limits.

How do visibility rules differ from constraints?

Constraints disable individual option values; visibility rules hide an entire parameter. Spokbee's documentation puts it plainly: use constraints for "you can't pick this option" and visibility rules for "this option doesn't apply to you". A hidden parameter leaves the form completely, drops out of the price and the quote, and its constraints are not evaluated.

Visibility rules are defined per parameter. You pick a target parameter, a condition parameter, an operator and a value, and the target appears only when the condition holds. The visibility rules documentation lists four operators:

The documented use cases are the ones every product team recognises: show "Engraving Text" only when "Add Engraving" is on, show "Leg Style" only when the product type is a table, show "Glass Thickness" only when the material is glass. Each one removes a question the buyer would otherwise have to answer with "not applicable".

What happens to a hidden parameter matters as much as the hiding. It is removed from the form with no blank space left behind. Its value is excluded from pricing. Constraints that reference it are not evaluated. It does not appear in the quote or order summary. When it becomes visible again, it resets to its default value. Those five behaviours let one schema serve a simple buyer and an expert buyer without two products.

How do constraints, visibility and pricing rules interact?

The three rule families hand off in a predictable way: visibility decides which parameters are in play, constraints decide which values are allowed, and the pricing engine prices what remains. Hidden parameters contribute nothing to the price, and blocked values never reach it. The number the buyer sees always belongs to a configuration that can be built.

Spokbee's pricing engine recalculates in real time and evaluates its own rules in a fixed order, documented on the pricing page:

A worked example shows the interaction. Take a panel product with a material parameter, width and height sliders from 20 to 200 cm, a glass thickness parameter and a premium finish toggle. The buyer picks glass. A conditional range narrows the width slider to 20–80 cm. A visibility rule makes "Glass Thickness" appear. The arithmetic constraint width * height < 10000 still guards the total area. The pricing formula charges by area, the premium finish adds a surcharge, and the price floor makes sure no discount takes the total below cost. The buyer switches to wood: the thickness parameter disappears and resets, its surcharge leaves the price, the width slider opens back up to 200 cm, and the area constraint keeps doing its job.

No spreadsheet does that. A spreadsheet can hold a price per cell, but it cannot narrow a slider, hide a row or stop a buyer at an impossible combination before the quote goes out.

What does the buyer see when a rule fires?

A buyer never sees the rule itself; they see its effect: an option greyed out with a tooltip, a slider whose range narrows, a parameter that appears or disappears, an inline error that stops them proceeding, or a price that updates. The page stays a product page, and every state the buyer can reach is one the factory can build.

The specifics are documented. When a constraint is violated, the configurator shows an inline error message and prevents the customer from proceeding. A count limit disables the extra toggle once the maximum is reached. A conditional range changes the allowed range of the numeric control. And because Spokbee is a 3D product configurator, the model on the page updates with the selection, so the buyer sees the glass panel at its narrower width rather than reading about it.

The same rules hold downstream. The quote a buyer requests is a PDF that captures the configuration and its pricing breakdown, and it can carry a digital signature and go through an approval workflow when a sale needs a human check (quotes documentation). When an AI agent configures a product through Spokbee's agentic commerce tools, it checks selections and prepares quotes using the same product rules, so an agent cannot talk its way into a configuration a buyer could not click into.

How do you build the rules in Spokbee?

There are two ways to create a rule in Spokbee: the constraint editor, where you choose parameters, operators and values, or plain language in the builder chat, which turns "show engraving text only when personalization is on" into a visibility rule. Both write to the same schema, and every publish saves a version you can roll back to.

A practical order of work, drawn from the documentation:

1. Define the parameters first. Give each one a clear label; the id is generated from it and becomes the name every rule uses (parameters documentation).
2. Add requires and excludes. These two types cover most dependencies and are the fastest way to make a configurator safe.
3. Add visibility rules for parameters that only apply to some choices, so the form stays short for every buyer.
4. Add conditional ranges and arithmetic constraints for dimensional and capacity limits.
5. Set pricing with a base price or matrix, surcharges per option, a formula for area-based products and a floor as a safety net.
6. Publish and test by trying to break it. Every version is saved, so a wrong rule is a rollback, not an outage.

The free Starter plan on spokbee.ai lets a team build a first configurator and its rules before committing. For a worked example of fitment rules on a real product, read how 3D wheel configurators turn diameters, widths and offsets into constraints.

Sources

• Gartner: Sales survey finds 61% of B2B buyers prefer a rep-free buying experience, June 2025, checked October 2026.
• Spokbee documentation: core concepts, parameters, constraints, visibility rules, pricing and quotes, checked October 2026.
• Spokbee customer stories: Stor-Loc and Alba Racing.