Product Dependency Logic
Incomplete quotes miss the cable, the brake, or the interface kit. Dependency logic pulls required companions into the configuration as soon as the trigger option is chosen.
Dependency · session
Servo / motor package
Motor
Cascade
Dependency trace
Selected: Motor 15 kW
Triggered
- D-14 · Controller → C15
- D-31 · Cable → 16 mm²
- D-40 · Cooling → Required
One decision changes multiple downstream selections
What this controls
Cascading
One selection triggers required downstream options
Required
Must-have companions added before price and approval
Complete
Fewer quotes that arrive at order missing parts
The challenge
The base option is on the quote. The parts that make it work are not.
Configurable products are not independent checkboxes. Choose a servo drive and you still need a matching motor frame, brake option, and power cable. Choose a control panel size and you drag along I/O cards and wiring kits. Miss one line and the customer has a price that production cannot ship.
Inside sales remembers most of the matrix on busy days. Dealers work from last year's accessory list. Applications notes live in a PDF nobody opens during a live call. By the time someone notices the missing cooler or encoder cable, the quote is already in approval or in the customer's inbox.
Constraints stop illegal pairings. Dependencies do the other half of the job: they force the companions that must travel with a selection. Without both, you either block too little or ship incomplete BOMs.
Inquiry to config to price to approval to order breaks when required lines are tribal knowledge instead of automatic steps in the configurator.
How it works
How Mercura resolves dependencies as reps configure
Product teams define trigger and companion relationships in Mercura: if this drive, then that motor class; if this option, add the interface kit. When a rep or dealer picks the trigger, required options appear, optional companions can be prompted, and incompatible follow-ons drop away. Cascades can span several levels of the product model. Rules-based configuration is where broader IF/THEN logic is authored; constraints hard-block invalid paths; this page is the connective tissue that completes a sellable configuration. Dependencies need ownership when catalogs change. They do not invent engineering relationships you have not defined.
Dependency cascade
One selection rewrites the downstream package
Toggle motor size in the hero to watch the cascade and rule trace change together.
What's included
What dependency logic covers
Trigger
- IF selected A, require or suggest B and C
Require
- Automatic addition of mandatory companions
- Cascading chains across multi-level configurations
Change
- Prompts when a dependency needs a human choice
- Clear messaging when a follow-on option is forced or removed
Remove
- Same dependency model for inside sales, dealers, and portals
- Versioned updates when engineering changes a companion set
- Works alongside constraints, rules, and bundling
The difference
Quoting with and without dependency logic
Memory and accessory PDFs
- 01 Quotes omit cables, brakes, or interface kits
- 02 Order entry adds missing lines after the fact
- 03 Dealers underprice because companions were forgotten
- 04 Applications engineering reviews incomplete BOMs
- 05 Customer renegotiation when the true scope appears later
With Mercura
- 01 Required companions enter the configuration on trigger
- 02 Price reflects the complete dependent set
- 03 Dealers and reps share the same companion rules
- 04 Standard paths reach approval without a missing-parts scramble
- 05 Catalog companion changes publish as dependency updates
Real-world example
Example workflow: servo drive packages
An automation supplier sells drives that must ship with a matched motor frame, brake option, and cable set. Inside sales used to tick the drive and hope the accessory matrix was followed. After dependency logic in Mercura, selecting a drive class pulls the required motor and cable lines into the configuration so the priced quote matches what production expects to kit.
Business impact
Why dependency logic sits between rules and constraints
Dependency logic is how manufacturers keep configurations complete, not only legal. Constraints prevent forbidden combinations; dependencies ensure required companions are present before price and approval. Mercura does not replace engineering judgment on novel packages outside the published model. Someone must own dependency updates when products change. For teams whose rework starts with a quote that forgot the cable, encoding must-have relationships in CPQ keeps inquiry, configuration, price, approval, and order aligned.
Business impact
Fewer missing required components
Must-have companions added before price and approval.
Lower reliance on product experts
Cascades encode what used to live in tribal knowledge.
Faster configuration
One selection resolves the downstream package.
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
Cascade resolved · companions set
See required companions appear on selection
Book a demo and pick a trigger option until the dependent lines show up before pricing 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.