User, Groups & Roles Concepts - OoB Roles & access controls overview

[Karim2]

Currently searching for a kind of overview/access control matrix for all the OoB roles in the standard process applications. Anything available?
Or any kind of best practice regarding the "user,groups and roles" concepts (& user support concept) with Service Now available?

[Adam Hutton]

There's a good list of current OOB roles here: http://wiki.service-now.com/index.php?title=Out-of-Box_Roles

It's best practice to not apply roles directly to any users - instead put users into groups and give those groups any required permissions.

For the most part, the "itil" role gives access to process applications for Incident, Problem, Change, etc. To get more granular, you'll have to create unique roles to segregate access to these applications and their respective tables, fields.

Hope this helps!

[Mwatkins]

Hi Karim,

I am not familiar with any published document that talks about best practice for user/groups/roles concepts. However, I know this concept is covered in some of the implementation and administration classes offered by the ServiceNow education services group. You might want to reach out to them via the portal, Training and Certification | IT Systems Management | ServiceNow . Specifically I think System Administration and Advanced System Administration cover these concepts in some detail.

There are documents that talk about how they work but as far as public documents that cover mapping business requirements to technical implementation strategies, I am not familiar with any. Here are a couple tips/guidelines that I've picked up over time:

• Roles can be granted to a group, to a user directly or through inheritance from a "contains" role. The preferable way is to have users belong to groups, and grant the roles through group membership. Granting roles via direct user assignment is not easily maintained and granting roles via "contains" roles is vulnerable to recursion.
• When creating ACL's, you should try to have them be based on roles. Using scripted ACL's is slower and harder to maintain than having them based on roles. If it really seems like you need complex behavior of a scripted ACL, consider that the script will potentially be running thousands of times per form load; when looking at a list, for example. You will want your script to be able to run in a couple milliseconds or less. Rather than writing an ACL script, it might be better to just have the ACL be role based and given out manually to specific users. This requires the administrator to manually assign/revoke the role to desired users, but the simplicity and efficiency of execution might outweigh the extra maintenance this requires.
• As a general rule, if you are using the Contains Role feature, you should only apply Contains Roles within a specific application. For example, if you are trying to give admin access to custom application X to a group of users, it is not a good idea to grant the role through a contains role on itil; effectively giving all itil users the u_x_admin role. What if you do not want some of the itil users to be able to administer application X? It is better to create a group for Application X Admins and grant the u_x_admin role via the group. On the other hand, if you have built a custom application X and you want to have roles for both u_x_admin and u_x_user it would be appropriate to have the u_x_admin contain the u_x_user role. This works because we know for certain that we will want all admins of application X to be able to also use application X.

Regards, Matthew