How to Create an ACL for Access to a Module that is NOT Based on a Role
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-03-2018 10:43 AM
I have a requirement to create an ACL to control the access and ability to view an entire Module in ServiceNow (Kingston) but NOT based on the role a User has BUT instead based off of the Dept/Division within the Company that is listed on their User Record (all of them work for the same VIce President.
Any ideas?
- Labels:
-
Scripting and Coding

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-03-2018 10:49 AM
You will need use the script field of ACL to compare the user dept.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-03-2018 10:50 AM
Click on the Advanced checkbox and you can add a custom script to do this. . .. however, the best practices method would be to create a group for those users, create a role for the access, then assign the role and users to the group.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-03-2018 10:51 AM
Here is what Chuck Tomasi suggested on similar use case.
The best practice is to grant access to modules/menus by role. This is much more efficient as roles are cached during the user's session - that's why you need to logout/login when given new roles. Using a script means you are imposing a load on the system where caching is not involved and could cause performance issues. What's more, later administrators may find your script difficult to find and/or maintain.
Link: https://community.servicenow.com/community?id=community_question&sys_id=c4cc8fe5db9cdbc01dcaf3231f9619e2
Thank you,
Ali
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-03-2018 10:53 AM
Is there a reason we have to avoid roles? You could write a BR on the on the sys_user table that on update, if it meets your criteria, it would add the user to a security group with a role attached. Using only ACL's you wouldn't be able to completely hide the module from the sidebar, users would be able to click on it just to see the "Removed by security constraints" message.
So, my proposal is:
- Create a new role
- Create a group, type = security.
- Add the new role to the new group.
- Write a BR on the user table. Put in the condition you want. Then in the script check if the user is already in the group, if not, initialize and create a new record on sys_user_grmember with the current user and the correct group.
- You may want to write a second BR (or add on to this one) to remove them from the group if certain things change (go to work for a new VP?)