We’re working on a menu security group restructure/refresh, as our epicor structure has not kept up well with changes to the business over the years.
A huge headache for us is being able to slot each individual user into a job-function based Security Group like “Sales”, “Inventory”, “Packing Manager”, etc. Sure, everyone fit nicely in the categories when they were created 10 years ago in E9, but the staff and positions themselves change so much over the years that nowadays no one fits well into the groups and everything is a one off. Not to mention, no one has a clue anymore which menus are granted from which security groups or what the relevant differences between groups are.
So, I’m mulling over how to approach a refresh in a way that won’t deteriorate so quickly. I think I want to shift away from job-function based groups and more towards grouping by the menus themselves… For example, “Basic Trackers”, “Financial Trackers”, “Sales Entry Screens” as groups of menus and then even individual groups for certain menus like “Part Entry” where we need to get that granular. This would mean many more security groups attached to each user and that managers would have to be good at communicating to IT exactly which menus their employees need. But I am optimistic something like this could work well, and also have some dashboard ideas to give managers more transparency into who has access to what. But I’m looking for feedback and other folks’ experiences as I have not seen a setup like this been done before… Every epicor implementation I’ve seen has done it organizing by job function.
P.S. Menu security is of course just one aspect of epicor security, and we are looking at other areas too, but I wanted to keep this thread focused on menu. I just watched @josecgomez and @bderuvo 's podcast with @Mark_Wonsil and plan to post some questions on those topics next!
We just went through this process with ours since it hadn’t been really reviewed since 2016 and was causing our current leadership some concerns around making sure people end up in the right spot.
We started with roles/responsibilities in general and then pushed that down into groups that look like the menu itself so that it’s easier for us to make changes based on the location of the menu items. Depending on the specific menu item it required being a little more complex but in general we split out setup folders separate from general operations/report folders.
It took some time to do but does seem to make it more streamlined for users to get to what they are looking for as well as for us to be able to manage requests for “need access to _____” and who needs to approve those requests.
I have just been through the whole process of rationalising our security which had evolved rather than been planned.
The key take away for me is to always have a security for every screen, report and dashboard.
I then uncheck the ‘Allow Access to All Groups/ Users’
It is then just a case of deciding which security group should be assigned to the function.
I use a spreadsheet to keep a record of this which needs to be approved by the relevant department head.
With this approach, the menu structure after that doesn’t matter so much as the security is at the functional level. However, if I could go back to the start I wish we had kept the Epicor standard menus.
I did ask Epicor is there was any way of reverting back to the original menus when we upgraded to Kinetic, hoping there might be a data fix/ script, but alas there wasn’t.
@aclements - I realize this is an old post.
Did you ever get your menu back to the base menu?
One way would be to export the menu structure from the Education database
Using DMT, delete your old menu. (don’t touch the system menus)
Import the menu structure you exported from Education
The one feature that would help break this headache free for me is to add the ability to have hierarchical security groups (at least one or two additional levels). Time for me to log in and review the ideas site .
I have found that breaking up the first level into mostly a paralleling of the Menu folder system - Setup, Gen Ops, Reports (Inquiry). The exceptions are for universally assigned access items, ie. Requisition Entry, or generally restricted tools ie. Inv. Quantity Adjustment, key sensitive reports that are excluded. These become ‘one-off’ groups. I also make a distinction between dashboards - inquiry based dashboards go in Reports Folders (by topic(s)) vs update-able dashboards -they go into Gen Ops by topic(s). This first level of sec groups then generally facilitates good access management, all built at the leaf app level of menu ids by DMT in an additive way.
User Roles or duties then end up being supported by sets of menu sec groups for supporting responsibilities and duties (Roles). This is where the hierarchical security group functionality would be very useful. Create Role security groups and build those with the menu sec groups. This works well if scoping of access isn’t razor tight, below the base folder structure. If it is, you might as well build your groups at the very leaf item level and ignore the topical folders entirely.
I’m imagining a customization now to associate menu sec groups to User Code(s) as Roles or Role Codes and use directives as an enforcement. Probably after we’re live…
What I think is nice about topical folder access levels for groups is that they are easy to alter and manage even through updates generally speaking. The base menu structure is one of the most standard things in Epicor, sure new items appear but the maintenance impact is low generally.
The other pipe dream is to integrate with AD groups to gain the hierarchical functionality but we rarely get to have those access rights ourselves and it is a an organizational feat to be responsive enough to adds moves and changes within both systems unless you are in a small and generous IT team.
From a Zero-Trust perspective, we want to give just enough access for as long as it is required. The trouble with nested groups is that it becomes far too easy to over-provision.
Like you, I want another layer: I would like to group capabilities into one identity and then combine those capabilities into personas. A personal would be attached to a user optionally for a limited amount of time. This provides several benefits:
One could mark combinations of certain capabilities as incompatible (PO, Receipt, Invoice Entry, Payment for example) to help ensure good separation of duties.
One could add a person to a persona for a specified amount of time to back up another user who is unavailable.
In smaller organizations, people may wear several hats so a persona is easier to manage than constantly changing job titles.
Potentially, one could use Entra ID App Roles to map to capabilities and then use Entra Groups to assign them. We could then populate Kinetic with the Groups | Capabilities/Roles.
In an ideal world this would include Service Security as well. We haven’t even started trying to implement that yet… it seems like it would be a nightmare to even keep it “in sync” with Menu security.
I agree with trying to be accurate and limit risk. There is always a reality of balancing trust, IT responsive times, administrative diligence, unforeseen gaps and obviously all sources of risk. We can be too lax or we can so refine and control a model, but as that is done, there are all sorts of impediments for both user and admin. There are real costs and advantages over the Privilege Bell curve. I just don’t want to have anyone’s workday consist of constant plate spinning to get the meaningful work done.
Also wanted to say thank you to you mark, Josez and Bryan for this podcast episode
Following menu structure deadends pretty quickly, it requires too many deviations and workarounds to make sense. For example, job tracker is in 9 different places scattered throughout the menu. Context menus point to one, then there are links from MES and etc. Ensuring that everyone who needs to use job tracker has access to every job tracker plus menu navigation available to at least one instance is a royal pain but less awful than supporting only the variety of navigation paths with auditing and maintenance.
Bottom-up is exactly what I did. Organized all destinations by role, independent of navigation. If a role has access to a destination, that role is granted access to every instance of that destination. Then recurse through the hierarchy and confirm that each role has at least one menu navigation path to each allowed process. Then I automated that whole mess because it needs auditing after every update, when new items pop up unannounced with default “allow-all” security. That was painful to implement but has proved to be extremely effective.
“All I really want is security that isn’t generally managed at the client.”
That comment was only meant to indicate how much tougher the task of building a model becomes.
The point I may not have made well is that I find it in practice more efficient to assign collections of capability oriented sec groups vs creating and assigning an ever increasing number of specifically tailored Role or Job Title oriented sec groups for a given user or group of users. The request variations never seem to end, at least in smaller companies.
Tom, also check out this thread and consider/consume Tim Shoemaker’s gold advice.
Security at the leaf, multiple copies of apps for differing groups… really good stuff! Security Groups/Users limited menu item access
.
