Row Security in JD Edwards EnterpriseOne: Part 2

In the last article we discussed the basics of Row Security and how it behaves when executed. In this article we’ll look at some of the different approaches that you can use to control Row Security in JDE EnterpriseOne.

Inclusive Row Security is easier to manage and has less impact on the system

In the interest of manageability and system performance, the first recommendation is to use for the Inclusive Row Security rather than Exclusive. As discussed in the last post, Exclusive Row Security increases the numbers of entries in the F00950 table, potentially degrades performance and makes reporting difficult.

Inclusive, on the other hand, is a much simpler method, where we control exactly who can see and edit specified ranges of data in the Database. When you look at the pros and cons, the question is why would you ever consider Exclusive in the first place?

Should Row Security be placed at the Role or User level?

Ideally all Security should be at the Role level, that’s why it was invented…

There are several factors that need to be considered when you are planning to implement Row Security within in a Role-based structure.

Firstly: are you using Multiple Roles? If you’re not, then Row Security will need to be part of every Role you give to a User (where Row Security is needed). This will increase the overall number of Roles. For example if you have six AP Managers working in different Business Units, they will each need different Row Security, so you will need to have a different AP Manager Role for each Business Unit.

This is not an ideal approach, so to avoid it some companies have opted for User-based Row Security.

For those who do use Multiple Roles, a better approach is to have two different types of Roles: Functional Roles and Row Security Roles.  In the example above we would have the AP Manager Role and a Row Security Role attached to the User. This is a much cleaner way of doing things, especially as it forces us to organize Row Security efficiently when we build the Row Security Roles.

But beware! All the Row Security for a User needs to be in one Role.

Attaching more than one Row Security Role to a User can create a big problem, because JD Edwards cannot work through multiple Row Security Roles where the same Table and Data Item is used. An example of this is where a User has two Row Security Roles, each of which specifies table F0006, item MCU and a different range of values. In this instance, JD Edwards will work through the “first” Row Security Role according to the sequence hierarchy and just take that Row Security, effectively ignoring the second one.

Many people have been caught out by this, so if it’s something you were not aware of, hopefully you can now avoid this pitfall and save yourself some time on having to redesign your Row Security!

Find out more about tools to help you manage JD Edwards E1 security

Alternatively find out more about JDE security management in general.