Why you shouldn't be scared making changes to security

We were talking to a customer last week who was scared about the implications of making security changes.  He was in the security workbench and wanted to change security for a particular role.  But clearly was concerned about the wider effect of making that change.  Who else might be getting access by changing the security?  Naturally this is a serious issue, if you have set up your security with process based roles, and have allocated roles to users, you need to be on top of who has been allocated specific roles so you can easily assess whether those users should be getting the access you are planning to change.  Fortunately, as an ALLOut customer, he was able to run our role relationship report to gain quick visibility prior to making the change.  We love being able to provide that degree of confidence!

Why you shouldn’t be afraid…

Role assignment changes: afraid you are going to accidentally remove security for something they already have access? or concerned that you may granting access to a critical process or information inadvertently? or even creating a Segregation of Duties violation?  As us about how to create preventative SOD alerts, report on your SOD violations, how to make security changes only to take effect after SOD approval.

If you are on the security workbench and you want to change security for a particular role, worried about clicking OK because of who else might be getting access? Ask us about how to report on role relationships.

Not sure the change you are about to make was is approved? Ask us about change control with approvals and work flow.

Uncertain if the data security update you are making is going to impact all of the users that need the new business unit or company? Ask us about how ALLOut can allow you to layer data security in ways that isn’t possible in standard JDE security to simply make one change and have access available for everyone that needs it.