Good morning, Part-y people. 
We did our 2024.2.16 → 2025.2.14 upgrade last weekend.
Since then, we’re noticing strange behavior around Engineering Workbench’s GetDetails process. Back on 2024.2, GetDetails from a Quote would show the 0-level assembly as well as subassemblies once a QuoteNum was selected.
Pictured below in our remaining 2024.2 environment:
Since the 2025.2 update, GetDetails is now showing only 0-level assemblies.
This is an existential crisis for some of our processes here, so I started digging into it a little bit.
We don’t have any layers deployed on GetDetails itself; Engineering Workbench has a couple of customizations through rolled-up layers, but none of them touch anything close to GetDetails.
Similarly, I have a Post BPM in place on GetDetails for some UD field nonsense, but again, we’re nowhere near triggering that BPM at the point pictured.
While troubleshooting, I noticed that the actual search event (GetDetails.SourceQuoteNum) which fires off when you set a QuoteNum on the form has
‘AssemblySeq = 0 AND Template = 1’ in the pre-loaded filter. Well, okay, that sure sounds like the behavior that changed.
Like anyone in way over their head would, I created a custom layer on GetDetails to start fiddling with it. I altered the preload filter and removed the AssemblySeq = 0 part.
For brevity, I’ll skip all the steps about actually hooking this up to the GetDetails process inside EngWB, but EngWB’s event was also overridden to point at the right menu/layer so that GetDetails launches with my testing layer.
I’m not sure how to attach a GFY here but the effect is that the 2nd-and-onward searches in the GD pane show all subassemblies, rather than just the 0-level. I’m not familiar enough with the search event widget to know what’s going on there and why. Selecting one of those subassemblies on the 2nd search pass, however, does correctly get mfg details from the subassembly.
I don’t like this at all, but a jank workaround for a mission-critical process is still a workaround.
Now, the part that’s really stumping me,
I checked how that event is laid out in 2024.2 expecting to see just the Template criteria in the filter, aaaaand:
…Wait… It’s been like this? This is the exact base GetDetails event that is running the first screenshot. Clearly this works (in 2024.2) as-is.
I put a ticket in about this last night, but I figured I’d see if any of y’all’d seen this in your own 2025.2 instances (or counter, this working-as-intended in 2025.2.13+). I am not the most-knowledgeable about AppStudio either, and I thought it’d be worth asking if there’s a different thing I should be poking at to get the first-pass search behavior to… behave.
This seems to have worked for us as recently as 2025.2.10 (during testing; that’s what we get for jumping to .14 for the update. We’re kicking ourselves, yes.) and the patch notes for 2025.2.13/14 do seem to have some other unrelated updates to GetDetails; I’m wondering if something broke downstream of another bugfix.
Thoughts? Questions? Comments?
… Like and Subscribe?
Anyway, thanks for any input you’ve got, friends.
