Security configuration can be a lot to handle, especially in Acumatica where we can configure user security down to an individual field. This is further complicated by how multiple roles over lap and how unset security setting default. With potentially unlimited possible combinations how can we determine what is the best configuration for us?
Best practices for Acumatica security would be to create base roles with heavy restrictions and add additional roles with access granted to specific screens or fields the user requires.
A few important tips to remember are
- Security follows the site map structure disregarding the 2017 R2 UI changes.
- “Not Set” by default provides access but once any other role has defined security at this level it will block access by default.
- IE: The IT role has granted specific access to the entire site. We create a new role called Sales which defaults to “Not Set”. If a user has only the Sales role they will not have access to anything.
- This is particularly relevant to any new screens, GI’s, Dashboards added to the sitemap
- The highest level of given security will prevail in the case of multiple roles
- The priority follows the inverse order of the drop down on the Access Rights by Role screen (SM201025)
- IE: Delete > Insert > Edit > View Only > Revoked > Not Set
- Using the above example if the user has the Sales role which is “Not Set” defaulting to revoked access and the IT role providing specific granted access the system will allow them access.
- We can use the Applies to Children check box to help automate the process. If using this feature be careful to test the changes as they can have unintended consequences. This is particularly true when changing security for the Hidden module in the sitemap.
- We must use the Access Rights by Role screen to configure security but to review existing settings, Access Rights by User and Access Rights by Screen provide a better view. The “Login As User” feature on the User screen can also be helpful for review and testing.
The most important piece is not to get overwhelmed by the sheer number of possible configurations, start at the top high-level modules and to work our way down using the Applies to Children checkbox. Once these broader restrictive roles are setup it is easier to identify fields or screens a user will require. We can then create a new role, assigned only to that user, granting access to only those specific identified fields or screens.
