Best Practices: Menu Maintenance?

We have several users who occasionally use various apps under certain “trees” in the menu structure that are sensitive. In the past, I’ve created a copy of the app outside of the sensitive tree and given that user access to it.

It’s a mess – and I’m pulling my hair out when we have attrition or new employees that “need the same permissions as John had…” – finding those special permissions like I’ve described above is a real pain (and the audit report is ugly as anything I’ve ever seen).

Overall, I’m extremely disappointed with the Menu Maintenance (especially for Cloud where I have copy everything that I want to touch).

Has anyone written a doc or found a resource that talks about best practices or tips for managing menu maintenance/security effectively.

Ugh! :man_facepalming:

1 Like

Sorry, I’ve only seen generic instructions is in the training course guides.
FWIW, here are a few things I’ve gotten in the habit of doing…
1.) Try to keep custom menu items in separate sub folders. Not always possible to keep 100% - but I find it helpful.

2.) I don’t like the security report so I built an indented dashboard with multiple search options.

3.) I make my changes to the menu/security codes in test system first. Then I’ll use multiple logons representative of all the users/security groups so I can REALLY know what they can/can’t access. Once I’m confident of my results I will deploy to Live.


Yes the OOTB menu and security is awful to deal with. I bit the bullet and made an entire new menu, menu security, and user security groups. Very easy to manage permissions now. I also made a couple dashboards for auditing purposes.


1 Like

Always use user group instead of user when dealing with security, ALWAYS

Try making a menu item with a unique menu security. This will help you to manage the Access for individual user, user group and no unwanted access will be available for the users.

Yes the OOTB menu and security is awful to deal with. I bit the bullet and made an entire new menu, menu security, and user security groups.

I did the same. I think this is really important because trying to control access at the folder navigation level rather than app level doesn’t actually control access, there are other ways to get to an app. Context menu ‘open with’ is about the easiest, if users can customize their home page they can just make shortcuts to anything, and then there’s DMT and CMD and REST and so forth.

This brings up something that’s really important to watch out for. Any menu that’s added by a software update will pretty commonly drop in as ‘Allow access to all groups/users’.

Using a User Group ALWAYS does not work always.

For example: 3 Report Menus are there and its not required to be given to all the members of the group. So Menu1 = 1 User, Menu 2 = 2 Users and Menu 3 = 3 Users,
In this example, its tedious to make separate user groups, instead, assigning users individually will help.

Respectfully, I ALWAYS add a group, even for a single person because it’s tedious to find and replace everywhere a person is assigned vs finding the groups that a person belongs to.

1 Like

Get ready for the Kinetic version where the Security and Menu will be in seperate processes. So when you want to know who can run a process, you will need to open up the menu security maintenance to see it! (one at a time)
Big step backward.

I also found creating a dashboard with the menu tree and the security codes very helpful.

1 Like

btw, add a “.” in front of user group description brings them to top of the menu security list

1 Like

I just made all menu’s to have no default access. Then I just give the group that user is in access to just that top menu and the subsequent menu they need.

That would work, but boy would be a real pain considering many applications are also available in other trees. That’s what makes the “please add new employee ‘Sue’ and give him the same access that we gave ‘John’ who she’s replacing.”

I appreciate all the input by everyone on this BTW. It’s a messy implementation for sure.