CMDB CI Permissions

[THank]

What is a best practice or what do others here use for permissions for adding or changing CI relationships in the CMDB?  We don't want the wild west and completely open permissions, but don't want to focus all CI relationship changes to a core group either, which would drive up resource requirements.  Thanks all!

[Paul Coste2]

Generally speaking, any user of a system should be granted access aligned with his or her actual role, either their job role, or their role in a business process.  So, in the ServiceNow CMDB, if a user is a configuration manager, it follows that they should have configuration manager-appropriate access to the CMDB.  If they are a CI owner, they should have owner-appropriate access to the CIs they own.  If they are a CI user, they should have user-appropriate access to the CIs they use.

Out of the box, ServiceNow does not implement true "roles" in a real business sense.  The roles implemented are more system-focused than business focused.  So you end up with roles like "itil_admin" or "asset" which are granted broad access to multiple modules, and which are rarely or never aligned with actual roles in your company (does your hiring manager post jobs for an "ITIL Admin?") 

So if you want to define the right roles, so that you have just the right people granted those roles, aligned with your business processes, then you will need to build your own access control to replace (or combine with) the out of box roles.  Identify the various roles in your business processes, what their responsibilities are, and what access they need to have in order to fulfill those responsibilities. Then define your system roles to align with the business roles (e.g. configuration_manager).  And as necessary, encapsulate sets of ACLs in smaller functional roles that can be assigned assign to the business roles.  And lastly, calculate the access based on a context of specific CIs, according to the groups and users specified on those CIs (owned_by, managed_by, assignment_group, etc.)

This is the ideal.  It certainly would take a bit of work to do, but it gives the most functionality to the right people with the least risk.  We have not yet taken this approach, so this is a theoretical best practice.  I'd be interested to know if others have successfully implemented such a model for CMDB or other areas of ServiceNow.

Note, however, that this may conflict with out of box functionality and access.  When we looked into this, for example, we found that using Proposed Changes didn't play nicely with defining true role-based access, since the person documenting the change may not actually have the right roles to edit the CI, but the Proposed Change uses the CI form, which would apply those ACLs.  It does not make a distinction between whether someone has the permission to propose a change on the CI, vs. actually implementing a change on the CI.