Having been very recently hired on to review and rebuild hundreds of dashboards and many other duties related to this weekend’s migration and not having an option for an on-premise working version of 2025.2, I find myself in deep mourning over the loss of Dashboard Maintenance tool. With it, I was able to review and dissect the myriad of dashboards of the task, and rebuild them without user inputs. Signoffs were quick and deployment easy. (The conversion tool makes a mess of the more complex Dashboard or fails entirely as you all know). Next week without it, and without a working Dashboard Maintenance Tool and copies of the old dashboard files to crack open and review (and no proper definitional documentation to look back on), I am going to have to rely on gathering specs through user narratives, test versions, signoffs etc (to do it properly). Adds a tremendous amount of time and effort. “Boo Hoo, get over it”, I know full well. And yes, the company woulda coulda shoulda, but their original author/expertise ‘left the building’ and it was hard to find the replacement. Great people, important work being done regardless!
I wished Epicor would have generously planned for some provision for digging up old built items within a system or from backups and allowing for rebuilding and redeploying, other than from scratch.
Is there some way to save out Dashboard Maintenance, the .dll and any supporting componentry and graft it into Powertools? Any thought on the viability of this?
The goal being ‘simply’ to review of classic dashboards (other classic UI customizations) definitional elements as its own guide to recreation in Application Studio?
I will greatly miss Dashboard Maintenance as well as previously mentioned as I am not proficient in App Studio. My approach when going full browser/cloud last year was to use the Generate Application feature in Dashboard Maintenance which creates the App Studio. This approach allowed us to get the dashboards up very quickly, including updatables and mulitple publish/subscribe, and working on browser as a first pass approach taking little time. This worked very well for us, including in Pilot 2026 testing, with just a couple of small tweaks required on a couple of dashboards. This made the undertaking much less insurmountable. I understand there may be issues with future modifcations on dashboards created this way but ours basically remain static. This approach allowed us to get the dashboards up quickly in browser and the vast majority did not requrie intervention. Those that require intervention can then be worked on. Hope this helps!
Maybe a consultant or professional services could help you out? If you export all of your dashboard definitions and BAQs now, they should have access to a 2025.2 environment where they could recereate them for you. It’s going to cost you, but at least you aren’t totally stuck.
Fantastic suggestion @mbayley and exactly what I did do for as many as I could.
Time consuming, but I can now review those I could capture.
Created a Teams mtg for each, because well it was there and straight forward for screen capturing and recorded it (it makes surprisingly small mp4 files). Launched and used each Dashboard, then opened again in Modify mode and opened all the properties at each element and strolled and scrolled through the tabs. @mbilodeau also suggested reviewing the data in the DashDbRef table to review the definitional elements contained there. That might help with the items I did not get to video document.
Perhaps I’ll add an idea on the topic, about a properties viewer for the Infragistics-based dashboards, but I kinda feel like it is a bit late in the cycle for this. We’ll see. I was perhaps hoping someone thought it possible/reasonably easy to do a bit o’ hack since the PowerTools client still interacts with to 2026.100 server-side. I know it is quite a simplification of the client server interactions, but if server-side code wasn’t explicitly removed (Ha, Ha, I crack me up sometimes), then I just got curious about how hard or easy it would be if Epicor could slide it back in.
And Support will accept Epicor Test Automation Platform files as well. Recordings are large but you can keep them in your SharePoint and share the folder to Epicor Support.
I have built dashboards from scratch multiple times and somehow they get some sort of funk (perhaps some sort of corruption??). Sometime it takes multiple tries or starting entirely from scratch to produce a functional dashboard. Without being able to actually see what is being written underneath as you go, then only the developer tools traces tell you what is going wrong and in the cases where funk is involved 100% of the time, it has nothing to do with what I actually built or directly configured. Low code/no code definitely has a major shortcoming when these gremlins can also enter the project.
Perhaps I save too often?? That used to be a mantra of Epicor education courses - “save and save often”. I save after every added widget or more often. The possibilities of what’s gone wrong seem endless or at least shrouded in mystery.
Example, Date ranges (‘kinda handy’ to preserve the performance of the query when parttran or labor details etc are involved) via from and to parameters sometimes works first time, other times ‘Forgetaboutit’. The frustrating thing is that I am following the exact same sequence of construction and it seems as though sometimes I get lucky and it works in preview and ongoing, other times it doesn’t work in preview, I close, save again, publish etc and log out of Epicor entirely and on re-entry it a dashboard will then work, other times it never works and I cannot determine a process root cause… only the gremlins know and I have no way of interrogation - what comes from the trace seems from unrelated to my data or datatypes or formats etc. With ther BAQ editor, at least I can see the query as I would write in in SQL and I can even generate the execution plan and see how it intends to process the request.
In Application Studio (BLACK BOX, and I mean the exact opposite of a flight recorder for analysis of what went wrong), sure you can see what you typed and save in the UI (unless it was typed in the json editor which eats text info all the time and doesn’t seem to save it! Save the text even if it is of incorrect syntax and allow me to review and edit it, @#$%!!!). The Infragistics Toolset used in the ‘Classic’ UI was both knowable and known and predictable in my experience. Perhaps that came from an ongoing maturation of the toolset. I hope Application Studio is a work still in process, because from my perspective, it is still far from mature and robust in the sense of it’s process of internal definition and integrity/consistency. Focus on that and all the other quirks inhibiting successful building before presenting 11 ways/places to bind or have 5 layout organizers for groups of fields.
I feel for the end users who shouldn’t suffer for these shortcomings and all this change - they just want stability, consistency, reliability and all of that seems to be in flux for them. I feel frustrated that I cannot provide them an even exchange when it comes to the UX, other than the speed of it which is greatly improved from the old client. Please forgive me, I know I am not alone in these observations and frustrations.
“Venting/Rant completed. You may now return to your regularly scheduled chaos”
Wooo, I was not at all familiar with this tool or this post, Thank you @Mark_Wonsil !!
I will give this my attention asap…
lol, that is as soon as I resolve the cause the ‘out of the box’ material tag not printing after this weekends ‘Upgrade’ that just came to my door.
Thanks so much regardless, I do so appreciate and admire this collection of compassionate and generous group and those of you who can hang on the largest waves and leading edges. You all amaze me!!
That’s just it - the point of frustration, I cannot tell if the export would or wouldn’t be functional at export time to return to, at least as far as I could tell until it has some real functionality to test. If I could match a creation process step to the point of corruption via some xml, csv or other construction log or spec (or both), it might show where the corruption occurs. Is it possible to crack open/decompile the app as written by app studio as you go?
I’ve found that Claude (and probably any AI of your choice) can understand the Dashboard export XML files so if you have them you can let the AI look it over and make documentation to help you rebuild it in Kinetic.
Even better, if you have EpiDev it can read the data from your database directly and assist with the Kinetic uplift.
Randy! You just made my day. I don’t think I would have thought of having AI look at the export files and suggest the method of construction in App Studio - Brilliant!
Thanks for this EpiDev extension reference as well. I will review it - Gabe is a High Wizard so it must be amazing. This company is cloud hosted so Direct access to the DB is not available… and quite frustrating, having been involved in on-prems historically.
So it’s a different thought process. AI is very very good at reading structured flat files like JSON and XML. It is also very good at comparison. EpiDev does that plus more in one tool, without all the manual handling
