Exclusive & Inclusive Row Security
While Exclusive can be used to “Manage Exceptions” and the E1 installation defaults to this setting, Inclusive is considered the stronger method for effectively managing data security.
Row security in JD Edwards (JDE) EnterpriseOne (E1) is used to protect the data in tables from being viewed and/or updated by unauthorized users. There are two strategies for implementing Row security (Exclusive or Inclusive). While Exclusive can be used to “Manage Exceptions” and the E1 installation defaults to this setting, Inclusive is considered the stronger method for effectively managing data security for a true closed system and to ensure a more painless audit.
Exclusive Row Security
Exclusive Row security works by restricting view and/or update authority to a record or range of records (data) – e.g. Address Book Search Types or ranges of Business Units or Companies. One issue with this is that the system load is increased as all records are fetched and then the ‘excluded’ ranges are removed. Exclusive Row security is typically more difficult to report on as ranges of records have to be ‘excluded’ and therefore those that are accessible must be inferred without being explicitly stated – the more records that are used the more complex this becomes.
Inclusive Row Security
Inclusive Row security works (in the opposite way to Exclusive) by granting view and/or update authority to a record or range of records (data) – e.g. to a Business Unit(s) or a Company(s). The Inclusive model typically only contains specific ranges of data that are available to a user or role. Setup, troubleshooting and reporting are therefore simplified. Inclusive Row security typically leads to less records, better system performance and is more widely used by the E1 install base.
Converting Row Security to Inclusive
There are some very serious implications when switching Row Security methodologies up to and including locking users from all data inadvertently so please be aware of these before any changes to how the system behaves are made.
This means that any existing row security data needs to be converted to meet the new criteria. Any critical data must therefore first be tested when using the new Row security methodology (preferably employing a different security table) to ensure that there is as little impact to the business as possible.
ALLOut software utilizes automates the conversion with a UBE that has been specifically designed to convert Row security records from Exclusive to Inclusive with an interactive front end to ensure the Processing Options configure this to run just the way you need it to. Let us help you take the work and worry out of this conversion. While optimizing your system setting and simplifying your audit.