Using multiple roles and had helpdesk queries about why your users can’t access certain programmes, despite having a role that should give them access?
When applying object level security, you need to consider how E1 checks for security. When a user signs in, the system first checks the user ID for security, then it checks the roles that user has, and finally it checks *PUBLIC. Fundamental to the way security works in E1, this is called the JDE security hierarchy, or sometimes officially the ‘net effect’.
What does this mean for you?
If you get a helpdesk call of this nature it needs to be resolved or you may end up with data integrity issues as users don’t update records they can’t access.
So what can you do?
1) change the role sequence: time consuming and could create unintended consequences
2) add security exception records: not advised as it flies in the face of Best Practice role-based security
3) create a new role: but you’ll end up with an over complicated role set.
Ideally you’ll use our CombiRoles tool, using process based roles, allocating multiple roles to a user and allowing the ALLOut Fix/Merge process to automatically adjust the Role Sequencer conflicts for you.
Learn more about our multiple roles solution by emailing firstname.lastname@example.org