App-Open issues : Are we the only company in the world experiencing this right now?

[mbilodeau (Mathieu Bilodeau)]

Hello all,

Since the last couple of weeks, gradually, a lot of vanilla buttons/events started to throw errors when trying to launch a menu. For example, the “Express Part Checkout” menu has a “Launch Engineering Workbench” option, which throws an exception of type "There is no active menu available for the app Erp.UI.EngWorkBenchEntry and layer combination.

Now, the rather important “Start Production Activity” button on the MES throws the same error:

Same thing with the “Launch Edge Agent Configuration” of “Company Maintenance”:

The issue was sent to Epicor (case #CS0005345768) by our admin and the support agent had no effing clue what was going on. Our admin spent a lot of time screen sharing and receiveing questions about security, and there was no way that they were going to address the issue in a timely fashion considering the importance of “Start Activity”.

When our admin told me about this, I quickly opened App Studio and “overrided” the vanilla “App-Open” event/widget. Here is the quick fix we implemented:

We implemented the same thing with “Start Production Activity”:

We documented this “quick fix” and sent it to support. This the answer we received from them:

Today, this Support Case was transferred to the Tools & 3rd Party Support Team, asking us to review.

Regarding these comments:

1. As quick fix, we created a new customization layer on “MES” and modified the “App-Open” widget of “On Click” event of the “Start Production” button to call the menu ID instead of the application name. Here are screenshots of the original customization layer : (3 attachments)

2. If you can fix the situation on your side it would be perfect, if this case can be approved as a bug to be fix

We have already submitted similar Problem Cases to Development, and given the Security Enhancements Development made to Kinetic 2025.2, this is Not a Bug, and what you call a Work Around, are now the recommended steps in 2025.2

Ok, nice, so our fix is the “Recommended steps in 2025.2”… now why the f%&$ are we supposed to implement it ourselves ?!? Can’t they fix those widgets before they start falling apart one by one ?

Anyone having the same issue ?

[Randy (Randy Stulce)]

In 25.2 it’s the opposite where you need to specify the appname not the menu ID --usually, as there are exceptions.

[leonardpothier]

Yep., from my experience though it only seems to happen when you have a customised screen, Epicor does not touch the customization and it is holding the original value, AFAIK (or remember at least) base forms don’t have this issue, could be wrong though but everywhere I have personally seen it, I had a custom layer at play on the screen that was making the call.

Corrective Action from DMR

I believe you actually want to remove the layer and repoint the app to the menu id, not that full string.

No Active Menu available

In 2024.1 most of my slide outs were calling Menu IDs with a layer defined, both in the menu id and in the call for the slide out. I ended up having to remove the call from the slide out ANDF copy the Menu IDs tot he current company for all of my companies, it seems the All Company flag is not honored in 2025.2. If I go through the menu for them normally, they all work but calling them this way did not seem to translate.

And it seems like in 2025.1 testing I had a slightly different but somewhat related problem, we skipped 25.1 so I did not do much more on it:

Kinetic-mes-browser - DB deployment issue

Can you launch that item & layer through Application Studio? I had a similar issue with my testing except that my live is 2024.1 and in it you assign a Menu ID and Layer but in 2025.1 it has changed to giving it the Program Name and Layer, updating mine from Menu ID to Program solved the problem for me. It looks like you already have the program in there so the next thing I would check is to make sure you can access it through Application Studio and that the layer is published.

[SergioMadrid (Sergio)]

I saw this issue back in the days when working with customizations opened through sliding panels. Basically, Kinetic was jumping on using app name + layers, then MenuIDs with layer name(s) on the next version, then a just Menu IDs next next version, then a prayer so it can work on the latest version.

So, yes, I know your pain, I was there for a while.

[Randy (Randy Stulce)]

You forgot about making a sacrifice to the Kinetic gods.

[corey.k (Corey King)]

This issue bothers me to no end; I created an idea to revert the security changes but they closed it stating this:

@corey.k

It appears Epicor has closed the idea, as they plan to address the tedium of fixing these issues.

We are taking action to remove the labor intensive nature of configuring cross application links with customization resolution, however we are going to close this idea as we’ll be taking this forward via support with improved instructions and some additional bug resolutions that are causing this to be necessary more than intended.

[dgross (Debbie Gross)]

@mbilodeau

Anyone having the same issue ?

I am on my 3rd issue since we upgraded to 2025.2.10 over the weekend – so just 4 workdays into this release. In each case it requires a customization to an app-open changing the View to Menu ID.

1. Launching Corrective Action from DMR Processing was throwing the error shown in this post. We didn’t have a custom layer on DMR processing but did on Corrective Action. If I removed the custom layer from Correction Action it worked as expected but we need this custom layer. Used this to resolve Corrective Action from DMR - #14 by leonardpothier
2. PO Link from New PO Suggestions > Generated POs – this didn’t throw an error but it took the user back to the New PO Suggestions Main Grid instead of opening PO Entry. Same basic issue, we have a custom layer on PO Entry but not on New PO Suggestions. I have a case (CS0005342878) open on this as it was my first and I hadn’t found this post yet.
3. Engineering Workbench button from Part Maintenance – this didn’t throw an error but it took the user to Method Tracker instead of Engineering Workbench. Here we have a custom layer on both Part and Engineering Workbench but if I remove the layer from Engineering Workbench it resolves the issue.

I have also tried copying the base layer and using it as the Kinetic Customization on the menu – issue still presented. So basically, you can’t have any Kinetic Customization on a menu and have the link/button/action from one menu to another work as it did prior to this upgrade…if the app-open has the application name in the view. This sounds like a to me!

So, rather than fix what they broke they are going to make multiple customers create multiple customizations to correct their issue. These workarounds are not simple – they require figuring out the correct events/controls, copying and creating custom replacements as you can’t update the vanilla events/controls…which BTW would make things so much simpler.

[mbilodeau (Mathieu Bilodeau)]

I got on a Teams call with support and basically they cannot acknowledge the problem as a “Basic functionality bug” since the customer has created a layer on the menu to be opened. The support guy kept telling me “if you delete/remove your customization layer from the menu, it works, so this is not a base functionality bug but a customization bug. You (the customer) created the customization, and we are not responsible for customer customization. It is your responsibility to test your customization on each update and fix whatever is broken on your customization. The problem is on your (customer) end”

I argue with him for a while and, I mean I’m not proud of myself, but I used a very “coarse” language and may have lost my temper. He transfered my ticket to the support team responsible for customization…

Lately support has been a royal pain in the ass. And then the last update made processes crash and we had to get data fixes…

[GabeFranco (Gabriel Franco)]

So I have this problem with a couple of layers and I was thinking about it.

The basic issue is, the base layer wants to call a base layer, but you removed the base layer from the menu because you want people funneled into your customized layer.

It seems like we can run a post on CheckMenuSecurityForUser that returned no access but we want it to, return that it’s good if the user has access to that app but with a different combination of layers, intercept the GetApp call in pre and do a check as to what layers are visible on the menu, feed the user those layers instead.

I can imagine there might be some downsides to that, but it seems like that would be a good fix without having to modify a bunch of base layers.

Thoughts?

[Randy (Randy Stulce)]

@mbilodeau

The support guy kept telling me “if you delete/remove your customization layer from the menu, it works, so this is not a base functionality bug but a customization bug.

I got the same BS response on our ticket about this. So basically we have to make a bunch of customized layers just to add the layer to the open app event.

[mbilodeau (Mathieu Bilodeau)]

My general opinion on this subject is the following :

• In the smact client (classic), when I create a customization layer on a menu and set it up in menu maintenance, it works just as intended
• In Kinetic, Epicor is providing the framework and guarding rail so that the customer can customize menu within the approved boundary. We were sold the idea that our customization would be “upgrade firendly” if we stay in the framework and use the widgets
• We are creating customization within thoses boudaries
• The open-app does not work, which is supposed to be since we used the customization tools and framework
• I have the ability/knowledge to implement a fix but, by doing so, I may be creating a technical debt, meaning that I will have to delete/clear that stuff eventually

My conclusion, the customization framework is at fault, please fix it

[hkeric.wci (Haso Keric)]

I overheard a senior Epicor Executive say the Quality of Development output is out of this world in the last year. Not sarcasm, ill avoid the name.

[aosemwengie1 (Alisa Osemwengie)]

Support says the fix is simple - just make sure the combination of application/layer in your event exists in the menu where the user can access it. I have now come across two cases where it still fails.

1. Method tracker - the system menu item references EngWorkBench in the classic portion of the menu item. This appears to confuse the app open widget into thinking the specified combo of method tracker/layer doesn’t exist even though it does.

2. The app you are referencing exists in a location the user does NOT have access to in addition to the location they do have access to, and the restricted location comes “first” in the list. Then it says your user doesn’t have access instead of continuing down the list to find the one they do have access to.

[dgross (Debbie Gross)]

@mbilodeau

It is your responsibility to test your customization on each update

Interesting…One of my users just confirmed that they tested the Engineering Workbench button from Part Maintenance in PILOT for the 2025.2.10 upgrade and it worked as expected. Their testing was completed on Mar 2 and our Prod/Live environment wasn’t upgraded until Mar 20…so this change occurred between then. I see there is a .14 & .16 but we haven’t gotten these versions.

[dgross (Debbie Gross)]

@aosemwengie1

Support says the fix is simple - just make sure the combination of application/layer in your event exists in the menu where the user can access it.

In all the cases I am dealing with the users have access so this is not true.

[aosemwengie1 (Alisa Osemwengie)]

Hey I am just saying what support said, not saying its true lol.

[dgross (Debbie Gross)]

Sorry - My comment wasn’t directed at you…more that support doesn’t know what they are talking about.

[sb_orion (Susan Boynes)]

We ran into this if the user previously opened MES and was still consuming an MES/DataCollect license (per Session Management) and were trying to open an option that requires the Default/Office license. Log out to release the MES license and log back in to resolve. Also, it the user truly did not have security access to the menu option.

[NateS (Nate Schoonover)]

@Randy

making a sacrifice

“Does it have to be blood? Does it have to be human? Does it have to be mine?”

[Adam (Adam Szymanski)]

Re: “There is no active menu available for the app Erp.UI.EngWorkBenchEntry and layer combination, The menu may either be disabled or access has been revoked. Please contact the system administrator”

We have/had the same issue on 2025.2.14 on prem. We have a customization layer for EngWorkbench. Error seems to be from a personalization on that layer.

Solution: 1) remove ref to customized layer in menu maintenance, 2) export layer in app studio, 3) delete layer in app studio, 4) import layer back into app studio, 5) set custom layer again on menu maintenance.