Basic Security Setup Newbie Questions

Epicor ERP 10
1

I’m new to Epicor and working on security setup for a small company.

Based on posts from this site, I am looking at setting security for all menus (not just the top of the menu tree to just hide the subtrees, due to potential context menu access) using DMT by creating security groups based on the menu structure, such as SALES, SALESSETUP, SALESRPT, SERV, SERVSETUP, SERVRPT, FIN, FINSETUP, etc. They are a small firm and didn’t want to get too complicated, so matching the user groups to the menu groups seemed the simplest method to split the functional areas.

Based on info on the Epicor training site, I was intending to create equivalent UD Security IDs (UDSALES, UDSALESETUP, etc.) and assign those to the menus in each subtree. This seemed a bit reversed from what I have done on other ERPs, but appeared to make sense based on the Epicor training pages examples, and seemed like it would work to allow me to specify specific security for each occurrence of the menus like UOM that have multiple occurrences in different areas, but sharing the same Security ID on every occurrence by default.

I then noticed that the 10.1 Sys Admin manual had a warning about standard menu items like AR Invoice Entry reverting back to its original security code when service packs were applied, which seemed strange, since the AR Invoice Entry was the actual menu used in the Epicor training example. This was my first moment of doubt, as a service pack reverting the recommended security method was disturbing, but I found the 10.2 Sys Admin manual and the warning was gone, so I hoped that the process had just changed between versions.

I ran a test on the Financial Management portion in our Test system and it seems to be working correctly, but then realized that I had not excluded the menus marked as “Security Manager Only”, so those were now in the standard FIN groups. I figured I could just set those menus to the original Security IDs, as they were already locked to “Security Manager Only” anyway (and exclude them in the actual final DMT upload), but then noticed that those screens included things like Bank Account setup for AR, AP, and Cash Management, which I would consider FIN functions, not Security Manager. So now I’m questioning why Epicor has “Security Manager Only” menus in the Financial Management section when they seem like they truly are finance functions. I can set them back to their original Security IDs, but I’m not sure if it even makes sense.

So my questions are:

  1. Is anyone else assigning a single UD Security ID for all menus in each Security Group? If so, have you had issues with Service Packs reverting IDs?
  2. Is there a good reason that Epicor has screens marked as “Security Manager Only” outside the “System Setup” and “System Management” menus? Isn’t Bank Account setup usually a FINSETUP function at most organizations?

I appreciate anyone sharing their experience with this. Thanks!

2

Welcome to the group! You picked an eventful day to start!

Very true, but to be clear, you should set security on every item. For example, on Order Entry and not just the Order Management > General Operations folder.

You may very well have meant that, but I just want to clarify. Otherwise, the strategy sounds perfect to me.

Also, some items cross boundaries (you can modify that; I’m just speaking of OOB).

Like Customer [Maintenance]. Here I clicked on the one in Order Management, but it has a security code (SEC154) that affects all occurrences of Customer (like in Accounts Receivable, or Field Service):

image
image709×352 27.9 KB

This makes perfect sense (it’s the exact same screen that accesses the exact same data), but it can surprise you when you see that a group has access to it “already” (let’s say you start with sales and then go to AR), and you say to yourself, “I didn’t add sales to the AR group!” Because you didn’t.

1 Like
3

Thanks for the quick response! Yes, it is an interesting day for the site, but fortunately I’ve been a member here for a little while or I would really be wondering about the look of the site. I didn’t expect April 1st to be so entertaining, but I am enjoying Clippy’s dad jokes far more than I would have expected. I’d be quite happy if they kept him around!

To clarify, yes, I did mean all items. I would normally call them screens, but called them menus since the Menu Maintenance seems to treat everything like a menu. I’m still working on the terminology as every ERP seems to have its own sub-dialect. :slightly_smiling_face: or perhaps :crazy_face:

Yes, the OOB cross boundary shared Security IDs became very apparent when I locked non-finance users out of UOM by changing the AR UOM to finance only. Thankfully it was only in test.

In my setup plan, I’m intending to

  1. set the Security ID for the top folder of each functional area to the report ID (for example UDFINRPT) since it would be most open and set all the report folders and report items beneath the same way
  2. set the General Operations items all with the general ID (eg. UDFIN)
  3. set the Setup items with the setup ID (thinking UDFINMGR, to more clearly indicate that we restrict setup functionality to each area’s manager.)

This structure would be the same for Sales Management, Service Management, Production Management, Material Management, and Financial Management. I am thinking that Executive Analysis, System Setup, and System Management can each get by with a single Security ID per, so just UDEA, UDSYSSETUP, and UDSYSMGMT.

That seems like the way the dots best connected what I would consider standard security practices and the Epicor training info, but this structure (changing Security IDs from OOB multiple IDs that are occasionally cross area to a just few unique UD Security IDs specific to each area) was never actually shown, and the slightly conflicting old documentation just made me want to ask for a sanity check. I am more familiar with linking Screen IDs directly to Security Roles than I am with the Menu ID to Security ID to Security Groups process.

Would you have an opinion on the Security Manager Only screens outside the System Setup area? I can just leave them with the OOB security IDs since those are already restricted, but with the few I’ve looked at in the Finance area, they seem like they shouldn’t be Security Manager Only in the first place. I would think the Bank Account setup would make more sense as a Finance Manager function than a Security Manager function, so I feel like I must be missing something obvious in their reasoning for putting it as Security Manager Only.

Thanks again for the feedback!

4

The checkbox, right?

Not really; I mean it’s a bit redundant, right? Like even if you say “no one can access this screen,” security managers always can regardless.

I feel like I am missing something, too.

Only thing I could see is if you want to add your groups but then lock everyone out in one swing, then let them right back in – without needing to delete all groups and add those groups back. (“Which ones were they…?”)

1 Like
5

Thanks!

6

And you’ll find you disagree with some of the folders.

Quantity Adjustment is in Inventory Management > Gen Ops.

Personally, I’m not cool with a warehouse worker doing adjustments to inventory on a whim. (Cost Adjustment is there, too. Eek.)

Yet INV/WIP Reconciliation Report is not in any financial folder. Why on earth not?

1 Like
7

Hi Blaine,

I wouldn’t recommend security on folders plus programs generally. It’s redundant. Assign at program level and then if the user has no access to any program in the folder, then they’ll see an empty folder.

Nancy

2 Likes
8

Hi Nancy,

Thanks for the response!

I realize it is redundant for the actual access and a bit more work to set up, but I figured it would be worth it since I have to document the access to validate it and figured it would much easier to have screenshots that show that the role only has the functional area folders to which the role should have access, versus trying to show that none of the other functional area folders actually have any programs available under them. That is my thinking, anyway.

9

Hello Blaine,

May not be an issue but there are a few “Mega Forms” that can be tricky:

Part Maintenance
Customer Maintenance
Supplier Maintenance
(maybe others I’m not thinking about right now…)

There are parts of each of these forms that you may want to split up by responsibility and not give the whole command to one person.

3 Likes
10

Thanks for the response!

They are small enough that I don’t think it is currently an issue because there aren’t that many staff to split responsibilities among, but I will confirm with them and try to set it up so it can be split without changing the roles if/when that is eventually needed.

11

I did my initial test DMT upload to Menu and almost everything worked as expected except for the Kinetic menus/screens with Option Type “K” which gave an error of “Table: Menu Msg: Program is not specified.”

It seems likely that this is happening because none of the “K” menus have anything specified in the “Program” field, but instead have the program showing in the “OldProgram” field. I was not actually specifying the program in the upload so I tried adding the “OldProgram” and blank “Program” fields to the DMT file, but continue to get the error.

If I try to get tricky and add the program from the “OldProgram” field into the “Program” field, it then throws the error “Table: Menu Msg: Program can only be updated on user-defined menu items.” So I would say DMT is smart enough to know I shouldn’t be changing the System Menu programs, but not smart enough to realize that the System Menu programs are default blank for Kinetic apps.

Have you ever noticed this? If so, do you know of a workaround for it? I tried manually updating the Security ID in Menu Maintenance and it does work, so it is possible to change, and there are 71 entries so it wouldn’t be incredibly difficult to manually change them, but a load with the others would be more consistent and easier to document as verified, since I can just print the load CSV as documentation.

Thanks!

12

Well, I applaud you for having a plan from the beginning, and that’s so much better than what we (I) did here… Our menu security has evolved rather haphazardly and I’ve always done it manually.

So, sorry, but I don’t know the DMT side of the menus.

2 Likes
13

Thanks for the quick response!

DMT seems pretty good so far, and the upload worked well except for the good old “why doesn’t that one piece work the same as the rest?” At least it was a consistent, identifiable error on a specific Option Type, so I can separate them out. I’m just learning the system and am finding that the Kinetic stuff seems to have an extra twist or two.

1 Like
14

We’re all right there with you as Keinetic is new and evolving UI in Epicor.

2 Likes
15

Nice to know I’m not crazy (or at least this isn’t the indicator!) :smiley:

16

I’m curious about the service pack updates question.
I’ve read through this thread and it seems that question was not explicitly answered.

The Field Help for Security ID says:
image

I’d like to take the approach described above, but don’t want everything to unravel when we apply the next service pack.

1 Like
17

Wow, that’s unfortunate.

So, now I see that I owe @bgilland an apology. I missed some of the technical term usage, and you clearly mentioned at the outset about the service pack thing. I was focused only on security groups, it seems.

I don’t know, but I can see that happening. @askulte has talked about changing menu item names and those reverting at upgrades, so I can see the security reverting, too.

I’ll say for myself, I just researched this for our company, and I have never done this. I have never changed the security ID of a system menu (screen/report/etc.). But I definitely have created new security IDs for screens that I created or duplicated.

Admittedly, it’s all been organic - I never had a huge plan around this except to make security groups and assign those. So even though I do appreciate the organization of the custom security ID idea, it does seem fragile.

18

Menu Security has to be one of the most laborious tasks for initial configuration. Ensuring to use the Principle of Least Privilege is made worse by the fact that typically when you do it, your not as familiar with Epicor and its security at the time.

There are a few posts around E10help that discuss best practices for setting menu security and reporting on it. No point setting it all up if you can’t audit it, or at least report on it. There was an Epicor Extension that did some form of access logging. Not sure if is available for the latest versions.

One thing I did want to point out is that if you don’t setup security on all menu items then you have the potential for a user to use the Open-with context menu to open a form they are not meant to have access to.

4 Likes
19

Yep, originally I tried to avoid getting group-happy, but I think the only solid way to audit who has access to what is to NEVER add a single person’s name to a menu item. Only groups.

Even if Jane is the only person that does job closing, still make a job closing security group. I have been undoing my sins of the past slowly like that.

Or more likely, 3 accounting people do job closing and then for some reason we let Jane do that, too, even though she isn’t in accounting.

So now I have to create the group and add Jane and the the 3 accounting people to it, since I am not giving Jane full accounting access. But it’s the right way.

2 Likes
20

I spoke with our implementation partner yesterday and they confirmed that the service packs would revert the SecurityID back.

Seems that the proper way to go about this is to create a requisite number of Security Groups, then selectively apply those groups against all the native (and custom) SecurityID’s, all 1700+ of them!

There is a Menu Security DMT available.

3 Likes