Row Security can be a necessity for so many JDE implementations however, very detailed row security can result in excessive effort put into maintaining the security records as well as system performance issues.  It, like so many other security initiatives, is a true balancing act.

This security allows the control of data within the system and is most commonly used in relationship to companies and cost centers\business units.  The key is to approach row security from a business perspective and not from a technical perspective. It doesn’t make sense to be securing things without a sound business reason – less is more!

How it Works

Row security works by controlling the ability for a user or role to View, Add, Change and Delete data.  JD Edwards offers two methods of applying row security, inclusive and exclusive. Exclusive security blocks access to a secured range of values (the Row Security ‘View’ flag is set to ‘N’).  All ranges of values outside of the designated range would be available.  Inclusive records grant access to a valid range of values (the Row Security ‘View’ flag is set to ‘Y’). When using inclusive, all values outside of the included range are automatically denied.

The example below is an example of Inclusive row security.  We will touch on the difference between it and exclusive later in this post.  This example shows that the security can be placed on specific tables or for *ALL tables to impact all tables in the environment that have the Data Item that is referenced.  For the role ZR-WEST below, the *ALL records grant full updates to all tables however the record referencing Table F0006 restricts the role from being able to delete from this table in particular.  In a case like this, the table specific record will take precedence.

Often, when Row security Roles are set up, the include a variety of records that represent all of the availability that is needed.  One difference between Row Security Roles and Application security Roles is that Row Security does not offer the opportunity to apply multiple security roles to an individual user that reference the same tables and Data Items.  As an example, if you have a role for Texas and one for the West Region that include different ranges of business units or companies and wanted one user to have both, you would need to create a new role that had all of the records involved to apply.  There is functionality in the ALLOut CombiRoles Module that allows you to utilize the existing roles and combine them to apply to a user so that any future changes can automatically flow through to all users that need the changed access without maintaining records in multiple places manually.

There are different perspectives to the issues that can arise.  Without row security, individuals may have inappropriate access to confidential data, or an organization may be noncompliant with regulations. If the security is not done properly, it can result in one sided journal entries, unbalanced balance sheets, or inventory transactions that do not affect all of the appropriate tables.

Best Practices

Some of the best practices for implementing row security are shown below:

• Use the minimum Row security possible in order to simplify maintenance and reporting. The more Row security records that are applied, the harder it will be to maintain and the more complex it is to decipher when reporting access to data.
• Where possible, apply security to *ALL tables.  This results in ensuring that data is protected without having to identify every table involved and adding extra records for each table.
• Inclusive’ security is recommended, which is not the default. Performance is normally helped a bit because there are fewer SQL clauses generated. And it is easier to use when viewing and maintaining records because you can see what is available to the role.  Security in multiple roles can be merged more easily (whether by a program or manually) because where you want to merge 2 sets of access, merging 2 sets of what you are restricted from can result in no access to anything.
• One thing to keep in mind is that it may look like financial information is protected by securing the CO & MCU data items, but there are other tables, which support financials, that do not contain the appropriate data item(s) and therefore will not be protected.  Be diligent in identifying these risks.
• As with all security roles, remember it is best to keep it simple with few records using ranges for row security and, defining roles that can be used for multiple individuals.

Tools

Whether you are starting row security from scratch and aren’t sure where to start, are looking to analyze your existing records to streamline what you have and need the best method or have exclusive security that you need converted to inclusive, we are here to help.

ALLOut security has a variety of tools available support your efforts.  Some of these are:

• Simplify the security maintenance process with grids or mass copy or delete.
• Define row security roles for a single company(s) or groups of cost centers and then use CombiRoles to combine the smaller roles to meet the unique needs of your users.
• Automatically convert exclusive row security to inclusive as simply as running a UBE.

Row Security in the final analysis is simply and additional security type that can be used to reduce

business risk. Understanding the business processes and the risks requires input from the business.

Defining the users, roles, security types, and the set-up of security usually rests with a special

security analyst or technical resource. It takes a team effort to understand and implement security in a way that meets the needs of both.