Access Control / Roles / Groups - Best practice
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-07-2015 02:17 AM
Hello all,
I made some fairly sweeping changes in our instance recently around access control rules, roles, groups, group membership etc, following the introduction of new resolver groups and change management functions in our organisation.
I followed standard practice in adding roles to Access controls, adding the roles to groups, and then adding the users to groups (no roles associated directly with users... ie always roles & users added independently to the groups).
But I've found that some users have been unable to access the fields and records I had expected them to be able to access. The issue has been easily resolved by removing the user from all groups and then re-adding them to the same groups. So the before state and afterwards states are the same - equivalent to the old 'switch it off and back on again' trick. It's as if the rules somehow did not 'take' the first time the user was added to the group. I wondered if anyone else has experienced this kind of issue, and is there a set of best practices to follow in terms of precise order the various elements are applied, eg always add users to a group before the roles, or always add the roles to the group before the users, or always add roles to the AC before adding the roles to the group? Or, should the order make no difference?
Thanks for any pointers.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-07-2015 02:44 AM
Hi Jamie,
You may find the below link helpful.
http://wiki.servicenow.com/index.php?title=Security_Best_Practices#gsc.tab=0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-18-2024 05:46 AM
this link desnt work anymore
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-07-2015 03:50 AM
Hi Jamie
When dealing with ACLs, caching is involved. There are scheduled jobs to clean cache at certain intervals. So it may have been a matter of timing when you were testing where the cache was not cleared to re-evaluate the updated ACL, giving the impression of the first time failure.
To verify if this is the case, you can clear the instance cache when updating the ACL before testing it again (cache.do). Beware that clearing the cache is quite aggressive so you will want to limit usage of it. (Just for reference: Troubleshooting Performance - ServiceNow Wiki)
Regards
Shahid
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-08-2015 09:14 AM
Thank you Shahid. I will bear this in mind when I update ACLs in future, and I will do some further testing in the meantime.