I’ve not investigated fully but it is using a dynamic slider widget in the event.
I don’t have any experience in Application Studio as of yet but just wondering if these slider pages can support either multiple pages or maybe setting the height to multiple screens high and having the user scroll?
Some of our QA forms have grown over the years and I can see more of them being multiple pages.
never heard of it. neat.
looks like a dynamic-panel-open action with basically no property values preceeded by setting TransView.DynamicFileContents to “{InspPlanSampleLst.SpecRevDynamicPanelContents}”
Which is encoded layer.json of one control per spec attribute populated from
Erp.BO.InspResultsSvc/GetInspParams
"InspPlanSampleLst": [
{
"InspPlanNum": "DIM",
"InspPlanRevNum": "INSP",
"InspPlanDesc": "DIMENSIONS INSP PLAN",
"SpecID": "SPEC-SIZE",
"SpecRevNum": "0",
"InspQty": 0,
"SpecDoc": false,
"SpecRevDoc": false,
"SpecDocDisplay": false,
"PartInspDoc": false,
"SeqPlan": "1",
"SpecDesc": "SPEC-SIZE",
"AltMethod": "",
"PartNumTrackSN": false,
"PartNumTrackLots": false,
"DefaultPlanPos": false,
>>> THIS >>> "SpecRevDynamicPanelContents": "[ \r\n {\r\n \"controlTypeId\": \"ep-row-navigator\",\r\n \"controlModel\": {\r\n \"guid\": \"8017d577-fa2c-4762-8fde-188c9fb18c32\",\r\n \"labelText\": \"Results\",\r\n \"id\": \"rowNavResults\",\r\n \"epBinding\": \"ResultsEntry\"\r\n }\r\n }\r\n,{\r\n \"controlTypeId\": \"ErpNumericBox\",\r\n \"controlModel\":\r\n {\r\n \"guid\": \"d1de1549-d038-437b-a596-98e100ae871f\",\r\n \"labelText\": \"THICKNESS\",\r\n \"id\": \"numNumber001\",\r\n \"epBinding\": \"ResultsEntry.Number001\",\r\n \"mask\": \"->>>,>>>,>>9.99999\",\r\n \"nullable\": true\r\n }\r\n},{\r\n \"controlTypeId\": \"ErpNumericBox\",\r\n \"controlModel\":\r\n {\r\n \"guid\": \"bb308d82-9913-407d-95a9-55a81ceced0c\",\r\n \"labelText\": \"LENGTH\",\r\n \"id\": \"numNumber002\",\r\n \"epBinding\": \"ResultsEntry.Number002\",\r\n \"mask\": \"->>>,>>>,>>9.99999\",\r\n \"nullable\": true\r\n }\r\n},{\r\n \"controlTypeId\": \"ErpNumericBox\",\r\n \"controlModel\":\r\n {\r\n \"guid\": \"4a7b5d6d-4942-41ac-9b5d-3850b871f155\",\r\n \"labelText\": \"WIDTH\",\r\n \"id\": \"numNumber003\",\r\n \"epBinding\": \"ResultsEntry.Number003\",\r\n \"mask\": \"->>>,>>>,>>9.99999\",\r\n \"nullable\": true\r\n }\r\n}]",
"SpecRevResultsEntryPageID": "",
"SysRowID": "45efaf36-d85d-4d85-99bd-ab5f53cd9246",
"RowMod": ""
}
]
unencoded looks like this:
[
{
"controlTypeId": "ep-row-navigator",
"controlModel": {
"guid": "8017d577-fa2c-4762-8fde-188c9fb18c32",
"labelText": "Results",
"id": "rowNavResults",
"epBinding": "ResultsEntry"
}
},
{
"controlTypeId": "ErpNumericBox",
"controlModel": {
"guid": "d1de1549-d038-437b-a596-98e100ae871f",
"labelText": "THICKNESS",
"id": "numNumber001",
"epBinding": "ResultsEntry.Number001",
"mask": "->>>,>>>,>>9.99999",
"nullable": true
}
},
{
"controlTypeId": "ErpNumericBox",
"controlModel": {
"guid": "bb308d82-9913-407d-95a9-55a81ceced0c",
"labelText": "LENGTH",
"id": "numNumber002",
"epBinding": "ResultsEntry.Number002",
"mask": "->>>,>>>,>>9.99999",
"nullable": true
}
},
{
"controlTypeId": "ErpNumericBox",
"controlModel": {
"guid": "4a7b5d6d-4942-41ac-9b5d-3850b871f155",
"labelText": "WIDTH",
"id": "numNumber003",
"epBinding": "ResultsEntry.Number003",
"mask": "->>>,>>>,>>9.99999",
"nullable": true
}
}
]
dynamic panels. who knew. pretty neat possibilities.
I haven’t tried a long one yet, but the built-in panel will probably render in a list like this example from the help file and it’ll be endlessly scrollable:
Alternatively, if you design your own panel, you can do anything like use tabs for sub-pages etc. here’s a single pager custom panel from help article:
Do you mind sharing a screen shot of this BPM? Has this been reported as a bug and scheduled for a fix?
Thanks for your help.
Graeme
I have not managed to get the details together yet to report to support.
BPM Post Processing on Erp.BO.InspResults.OnChangePartNum
Execute custom code
foreach (var row in ds.InspPlanSampleLst)
{
if (String.IsNullOrEmpty(row.SpecRevResultsEntryPageID))
{
row.SpecRevResultsEntryPageID = Db.SpecRev.Where(r => r.Company == Session.CompanyID && r.SpecID == row.SpecID && r.SpecRevNum == row.SpecRevNum).Select(r => r.ResultsEntryPageID).FirstOrDefault();
}
}
Thanks so much Ben. Do you have the inspections attached to the part? We have inspections assigned to job operations so I suspect we would need to adapt this for our purposes.
Regards,
Graeme
In this scenario yes. As it was just to test the functionality. So you will need to add the same logic to a different method as called by the screen probably something like onchangeOprSeq, if the bug exists there that is. 
Thank you everyone for posting that Epicor can now handle the entry better!!
I didn’t go full bore but was able to use Inspection results entry to enter data in a top to bottom fashion and it is similar to the custom form. At least enough to get data entry done!
I accessed it through Inspection Results entry
- Generate Test Set
- Then Select [Enter Results]
- Then select [Enter Results Detail]
Pretty sure the custom code no longer works.
This should work through the MES but right now there is a bug with Linux containers and the MES so I cannot get there to try it yet.
Included the form (note I have not made an application or layer this is raw built in Epicor functionality)
I have an old dashboard that parses the inspection tables and the results are in there!
However there is a bad side to this.
You can specify the order the items are to be in but this only goes for the horizontal entry not the vertical. That goes in the order you save the specification attributes in. Some of our plans have many dozens of items. It is not feasible to rewrite the entire plan if we have to insert an element.
Second bad item, any custom code is gone. I mean we knew that but for Epicor to not offer an easy way to fix it?
This needs fixing. In the meantime, you could conceivably reorder in dynamic panel json via Erp.BO.InspResultsSvc/GetInspParams POST-PROC BPM.
PS - signs are C# client-side code may be coming… 
I doubt that for regular Kinetic. Requires downloading a WASM binary for every screen.
My understanding is Inspection Plan Configurator is in ways like Part Configurator. Perhaps for those at least 
This was the old QA configurator. Only way to bring C# into the new QA forms would be to build a function with your C# into it. This implies you know how to call a function from Application Studio and that it works…
We have EQA don’t have Configurator. Unclear on the exact similarities n diffs between the two with respect to Configurator Designer. We understand Configurator Designer is classic only at this time. However, has it been said Configurator Designer WILL NEVER be full parity in Kinetic?
Josh;
Owning EQA in Classic gives you the ability to create an inspection configurator using most of the same screens as the Product Configurator. This was not supported in Kinetic and you can either use the default “vanilla” screens or you can create a layer in Application Studio.
I think most will agree that this is more sensible approach but they were late to the game as this only became available in 2025.2! I think you are right that feature parity will take a long time but I suspect very few are live with this to really know for sure.
We are 10 or so releases into Kinetic and basic instability remains so I am not to hopeful to give this to my shop floor without more testing. Our current plan is to move all our MES stations to the Kinetic screen and use the edge agent for QA.
We have already had a couple Classic forms break and support has just suggested using the Kinetic version. Wonder what calls about the Edge Agent will be told.
Short version… this wasn’t removed, it was intentionally re-architected, and now you have a different (arguably more flexible) path to get back to what you want.
Longer context…
When we originally built Enhanced QA, it relied on the Smart Client Product Configurator to render the inspection UI. That gave you a lot of control, but it came with real trade-offs… complexity in setup, and a UX that forced users through one question at a time. A lot of customers pushed back on both points, especially the lack of a grid-style experience.
During the Kinetic browser transition, a decision was made to remove the configurator dependency entirely and auto-generate the inspection UI. That’s why you now get the grid by default. No design step, no configurator, just immediate usability. For a large segment of customers, that was a net win… simpler, faster, zero setup.
But… it also flattened the experience.
If you had more complex needs, like vertical flow instead of wide grids, or embedding images, that flexibility was missing.
The important part is what changed more recently…
With updates in Application Studio (partially in 2025.1, fully in 2025.2), you can now layer customization back on top of the auto-generated grid. That means:
- You can reshape the layout (not locked into the default horizontal grid)
- You can introduce a more guided or vertical flow if that fits your process better
- You can surface images and enrich the UI again
- You can effectively recreate a “designed” experience without going back to configurator
So the model now is different:
- Out of the box → zero-step, auto-generated grid
- Advanced scenarios → use App Studio to tailor the experience
- If you had C# logic in the screens, you will now need to move that to an Epicor Function (just like other App Studio customizations)
It’s a shift from “design first” to “generate first, then refine”.
If you’re trying to get back to something close to the old configurator-driven experience, the path forward is App Studio, not bringing configurator back into the equation. Make sure you are upgraded to a version that has these new features and look at the help files for more details.
Thanks Tim.
Makes sense auto-gen helps a large segment of customers but seems like you’ve silently taken the entire ‘wizard-engine’ off the table for another segment of EQA customers.
Are you confirming configurator will NOT be an option for EQA in Kinetic and Product Configurator alone will benefit from client-side C# rules, validation, conditional navigation, etc?
Perhaps rebrand it ‘the module formerly known as Enhanced’. 
Yes, the configurator is no longer available for EQA… but in the Product Configurator, you still have server side UDMethods that can be written in C#… also the configurator supports C# for client side work as well.
Help article wanting: “Rebuilding a workflow engine using App Studio” in which the following are mitigated:
- Loss of enforced sequencing
- Loss of built‑in validation lifecycle
- Manual state and flow management
- Increased duplication of logic
- Higher risk to quality and compliance
- Greater design and maintenance burden