We’re running into an issue with the Kinetic Product Configurator and could use some guidance.
Environment:
Epicor Version: Kinetic 2023.1.14
Base Version: 11.2.300.0
Scenario:
We are trying to set up a dependent combo box. The goal is simple:
A user selects a Part from the first combo box.
Based on that selection, the second (and other) combo boxes should only show filtered values related to the chosen Part.
Problem:
No matter what approach we try, the dependent combos never filter correctly. They always show all possible values instead of the filtered subset. It seems like the parameter (selected Part) is not being passed to the other combo’s data source, or the refresh isn’t firing as expected.
What we’ve tried so far:
BAQ-based dynamic list
Set criteria in the BAQ.
Called Refresh.DynamicList("ComboName").
Result: List loads, but not filtered – it still shows all values.
User-Defined Method (UDM)
Passed the selected Part as a parameter.
In the dynamic list condition, checked that Inputs.PartNumber.Value is not null/empty.
Result: The list loads, but again, no filtering happens.
Configurator Lookup Tables
These only load static values. Doesn’t meet our need for dynamic filtering.
Additional Notes:
In earlier Epicor versions, we achieved this using reusable combos + event-loaded BAQs.
In 2023.1, the reusable combo option doesn’t exist, so that approach is unavailable.
Sorry to hear you’re having trouble.
FWIW, we’re using the BAQ method with parameters based on other combo boxes extensively. This has been working for us on various Kinetic versions, currently 2025.1.12.
There were significant issues in earlier versions of kinetic with Combo Boxes that includes filtering and refreshing. The best I can suggest is upgrading to recent release or see if there are any patches offered for your release.
In earlier versions (though I’m not sure about the current release since my company change), the condition rules for BAQ dynamic lists were problematic. I had to rework the process across all of our previous configurators to avoid using the condition rules. Once we implemented the new approach, everything started working correctly, with respect to filtering of dynamic lists.
In that event, call the parameterized BAQ and pass the value from the first combo box into the BAQ parameter (using the binding of the first combo box).
In the second combo box, set the View Name field to the DataView you just created. Under Advanced, configure the Text Field and Value Field to reference your BAQ fields (see screenshot attached).
Thanks for your efforts to help me,
unfortunately, in this version we dont even have any options for declaring dataview values,
reusable combo section dont have any such options. its just empty
We approached configurator setup a little differently than most. We added an extra tab to the Part screen and created UD fields there to maintain our configurator definitions. These UD fields stored the responses to our configurator questions, so as someone stepped through the configurator, they were essentially walking through the logic defined in the Part table.
For example, for optional paint selections, we structured the UD fields like this (these values were stored on the back side of each paint part):
Field 1: “PAINT” – main category
Field 2: “Liquid” or “Powder” – subtype
Field 3: The color description displayed in the configurator
In the BAQ criteria for the paint type, we’d set it up like:
BAQ Column Name: Field1
Condition: =
Value From: (static/fixed — I don’t recall the exact term)
Value: “PAINT”
That allowed the configurator to determine if the customer wanted liquid or powder. The next question used the same structure, but the second BAQ criteria referenced the previous answer to filter the available options.
The biggest issue we ran into was with the Refresh Dynamic List functionality. At the time, it didn’t behave correctly — if a salesperson selected an option, then went back and changed a prior response, the dependent value didn’t clear even if their previous choice was no longer valid. It created some potential for bad selections to slip through. Hopefully that’s been addressed in newer versions, but when I last worked on it, that limitation made kinetic configurators risky.
We also did a lot more things with ud fields and the configurator with storing information on the part itself, but this was how we handled your question.
Thanks for taking the time to share such a detailed explanation — really appreciate the effort!
I’ve run into similar situations myself — sometimes we have to get creative to work around functions that don’t behave as expected.
That said, in my case it feels like all the possible options are closed off, and I’m struggling to find a way around this one.
