Configuration Constraints
Hard stops at the configurator, not soft warnings after the PDF. Incompatible materials, ratings, and options disappear before approval and order.
Constraints · session
Industrial pump / valve package
Application
Body material
Unavailable: Food Grade requires Stainless 316L.
Pressure class
Unavailable: Food Grade requires Stainless 316L.
What this controls
Blocked
Invalid paths removed while selecting options
At selection
No waiting for a later engineering review
Shared
Same guardrails for reps, dealers, and portals
The challenge
The quote looked fine. Production said it cannot be built.
Someone picked a span band, duty class, and hook block that looked reasonable on the form. The PDF went out. Days later, order entry or the plant flags an impossible combination: hoist capacity exceeds the selected beam class, festoon rating too low for the trolley speed, control package not approved for the requested duty cycle.
Inside sales meant well. Dealers copied last quarter's configuration. Applications engineering was the unofficial constraint checker, until volume grew and they could not review every line. Soft warnings and tribal knowledge do not stop a determined click on Submit.
Without hard constraints in the configurator, you train people to remember exclusions, then watch the same invalid path return after every new hire and every new region. Price and approval still run on a configuration that should never have existed.
The pain is not missing product documentation. It is that engineering limits are not enforced where the quote is built: inquiry to config to price to approval to order.
How it works
How Mercura enforces constraints during configuration
Product and engineering publish exclusions, requirements, and bounds in Mercura. As a rep or dealer selects options, incompatible choices are hidden or disabled, required companions appear, and out-of-range values are rejected with clear guidance. The quote cannot proceed on a blocked path. Rules-based configuration is where you author the wider IF/THEN model; this page is the enforcement layer that keeps invalid combinations out of pricing, approval, and order transfer. Constraints need an owner when catalogs change. They do not invent product physics for you.
Constraint types
One connected canvas · three patterns
Exclusion
A + B → blocked
Requirement
A → B required
Range
4 ≤ Pressure ≤ 25
Constraints prevent invalid states. They do not cascade companion selections — that is dependency logic.
What's included
What constraint enforcement covers
Exclude
- Exclusion constraints: A cannot be combined with B
- Requirement constraints: if A, then B must be present
Require
- Range and rating bounds tied to selected options
Limit
- Immediate feedback when a choice would break a limit
Explain
- Same constraints in inside sales, dealer portals, and embedded flows
- Clear reason when an option is unavailable
- Versioned updates when engineering retires or adds a limit
- Works with rules, dependencies, and variant models
The difference
Quoting with and without hard constraints
Warnings and memory
- 01 Invalid combinations reach order entry or the plant
- 02 Applications engineering spot-checks complex quotes
- 03 Dealers repeat yesterday's mistakes from old PDFs
- 04 New hires learn exclusions from tribal knowledge
- 05 Rework starts after the customer already has a quote
With Mercura
- 01 Blocked combinations cannot be selected or submitted
- 02 Standard paths quoted without a human constraint check
- 03 Dealers and reps share the same guardrails
- 04 Catalog limit changes publish as constraint updates
- 05 Price and approval only see buildable configurations
Real-world example
Example workflow: overhead crane package constraints
An overhead crane OEM sells single-girder and double-girder packages with capacity classes, span bands, and trolley options that cannot be mixed freely. Dealers used to assemble combinations from a matrix in a PDF and discover conflicts at order check. After constraints are published in Mercura, incompatible capacity and span pairs drop out during configuration, and only buildable selections reach price and approval.
Business impact
Why constraints belong next to rules, not instead of process
Configuration constraints are the guardrail that lets channel teams configure without treating every quote as an engineering review. They complement rules-based logic and dependency models; they do not replace CAD, certification work, or judgment on novel requests outside the published envelope. Someone must own constraint updates when products change. For manufacturers whose worst days start with a valid-looking PDF that production rejects, hard stops at selection protect margin, trust, and cycle time better than another training deck.
Business impact
Fewer invalid orders
Invalid combinations blocked while options are selected.
Less downstream rework
Engineering does not rediscover forbidden paths after send.
Consistent enforcement
Same guardrails for reps, dealers, and portals.
Compare
Constraints vs dependencies
Constraints
Prevent invalid states
Food Grade + Carbon Steel → BLOCKED
A + B cannot exist together.
Dependencies
Cause other values to change
15 kW motor → Controller C15 REQUIRED
A drives B / C / D automatically.
Not IF/THEN synonyms — one blocks, the other cascades.
Configuration map
Product definition → rules orchestration → commercial packaging → valid configuration, price, and BOM
Product definition
Logic
Commercial packaging
Output
Valid configuration · Price · BOM
Valid configuration · paths guarded
See invalid combinations blocked before the quote
Book a demo and try a forbidden pairing until the configurator removes it before price and approval.
Let’s build together.
We empower manufacturers to master product modeling, streamline quoting process, reduce errors, and ultimately deliver the tailored solutions that customers demand.