Role Management FAQSummaryThe goal of this article is to answer generic frequent requests/questions ServiceNow Technical Support receives in relation to role issues. I if you have follow-up questions, please contact Technical Support. Table of Contents What are the important concerns to consider before activating the Contextual Security: Role Management V2 plugin?Why can I not delete roles for a user?How can I tell where this role was inherited from?I removed a Role from a group but I still see users having access?When granting access on my instance it locks my session, can we do run this so it doesn't lock my session?What is the snc_internal and snc_external roles?Is the roles snc_internal and snc_external chargable?Why can I not grant admin role if I am also an admin?When removing a group or a role the transaction times out?Why does g_user.hasRoles return false for my users?The hasRoles() methodMy users are showing as sys_id and not the actual name?Why are roles showing as empty on tables like sys_user_has_role, sys_group_has_role and sys_user_role_contains?What is the user: License.role.testing and why can we find a large number of deletes on sys_user_has_role daily in deleted records?Why do i not have any security admin how can i get this role back?Why is "Elevate Role" not working anymore? What are the important concerns to consider before activating the Contextual Security: Role Management V2 plugin? The Role Management V2 plugin is not activated by default for existing customer instances for good reason. There are significant differences between the prior Role Management system (which we will refer to as legacy) and the V2 mechanism. With the legacy system a user can have multiple records granting them a role. Depending on the complexity of a customer's user, group and role configuration this can mean a user having a large number of apparently duplicate records granting them the same role. These are not really duplicates because the legacy mechanism uses three fields to track where the role was inherited from: granted_by : the group which the user is a member of which has the role they have inheritedincluded_in_role: the role has been inherited from another role and this is a reference to the user's record in sys_user_has_role for the parent roleincluded_in_role_instance: a reference to the sys_user_role_contains record which granted this role to the user All three fields are deprecated and their contents cleared when the Role Management V2 plugin is activated (the granted_by field contents are changed to 'not-applicable'). This is explained in the Prevent duplicate entries with Contextual Security: Role Management V2 documentation, though the title is misleading as these only appear to be duplicates if you are unfamiliar with their purpose. The most significant impact is the deprecation of the granted_by field as many customers use this in their customizations around the management of groups and access to roles within their organization. Therefore if the Role Management V2 plugin is activated these customizations may fail to function correctly. With the legacy mechanism this does mean the sys_user_has_role table can be very large, which can impact the time taken to make group / role related changes as a large number of records may need to be added or deleted from sys_user_has_role and can influence the time taken for an upgrade if there is a change to the out of the box roles on the instance. With the Role Management V2 mechanism a user at most can have two records for a single role; one for a directly granted role and one if the role has been inherited from a group or other role. With the inherited role a new field, inh_count, records the number of times the role has been inherited and effectively replaces the need to have that number of individual records in the table. This is the reason the granted_by field no longer tracks the group a role is from because there is only a single record, instead the granted_by field is only used when a role has been delegated to a user. This does mean that the sys_user_has_role table can be significantly smaller once the Role Management V2 plugin has been activated, which can bring benefits to role related operations and potentially clone and upgrade durations. Therefore, before activating the Role Management V2 plugin a through evaluation must be carried out to determine if any of the three deprecated fields are being used by any customization on the instance. Why can I not delete roles for a user? If you look at the table User Role [sys_user_has_role] you will see a column "inherited" this means that this role was inherited from a role or group If this was false then the role was directly assigned to the User. Now if you wanted to remove that role, you can only delete the record when inherited = false. If it is true then you cannot delete the role directly, you need to remove the inheritance so either remove the role or user from the group/role this will then update all inherited records and remove that access. You will see a message like this: Some of the user(s) have been granted access via an inherited role or group. Please go to System Security -> Groups or the correct role to remove the user's access. How can I tell where this role was inherited from? If you want to know where the role was inherited, you can add the field "inheritance map" to the list view for User Role [sys_user_has_role] you can click the "Role Inheritance Map" link and it will provide you how this role was inherited. From this UI you can see where the role was inherited from. I removed a Role from a group but I still see users having access? This could be a few things so best to validate the issue. If it's not inherited you need to remove the role/user directly. If it's inherited you can click on the Role Inheritance map, and if the map appears broken then that is an invalid inheritence record that should be removed. This issue can happen if removing the role from the group and that transaction had timed out or been cancelled so all actions had not been fully completed. If you see these broken references please contact Technical support and they will be able to help you. When granting access on my instance it locks my session, can we do run this so it doesn't lock my session? This is a very common question, as when you grant a lot of users access to a group or role it can take some time to grant those roles and it will lock out your current session till it completes and you cannot do anything else during this time. There is another issue with this that while using your session the transaction does follow the current UI quota rules which by default is 298 seconds. So if the transaction to add/remove roles takes too long the transaction will not fully complete which will end up having broken references and access across the instance. We do have a solution to this: How to adjust granting of roles and groups to use background jobs instead of Foreground job. This will mean the session will not be locked and also the transaction will use background processing so can run for a long time without timing out which should fix your user/role issues. What is the snc_internal and snc_external roles? These roles come from the plugin "com.glide.explicit_roles" it provides the instance with the new snc_internal and snc_external roles, preventing external users from accessing internal data.Enterprise users (employees) must have the internal role while non-enterprise users (non-employees) must have the external role.snc_internal:This role is assigned to all internal users (employee or internal to an organization). Any new user that gets added also get this role during their first login/impersonation, provided the user doesn't have the snc_external role already assigned. All the existing ACLs without a role are patched with the 'snc_internal' role. For new ACLs, the Now Platform automatically adds this role if the ACL is saved without any role. snc_external This role indicates that the user is external to your organization and should not have any access to resources unless: You explicitly allow access through ACLs for the snc_external role, orYou explicitly grant them additional roles. By default, users with the snc_external role are unable to access non-record type resources as well, such as processors and UI pages.Reference:https://docs.servicenow.com/bundle/paris-platform-administration/page/administer/security/reference/explicit-role-plugin.html Is the roles snc_internal and snc_external chargable? These are free roles and have no additional costs involved. Here is more information: SNC Internal & external roles. Why can I not grant admin role if I am also an admin? This issue can come from scoped roles attached to the admin role, which you may not have access to which is causing this issue. So look at the roles inherited from admin and you may have a scoped role which is to be granted that you yourself do not have. There is a change in Newyork that the system checks if the user that is assigning a role is privileged role or contains privileged role. If it has a privileged role, then the user cannot add the role unless he has that privileged role. One scenario of this is the role: sn_templated_snip.template_snippet_admin being contained in the "Admin" role, this role is a privileged role. The reason this was linked to admin was to avoid any issues with using this specific application. More information is here: The system user cannot add the "Admin" role if it contains the scoped "sn_templated_snip.template_snippet_admin" role. When removing a group or a role the transaction times out? When making a change to role, group and inheritence there is an issue where the transaction follows the current UI quota rules which by default is 298 seconds. So if the transaction to add/remove roles takes longer then 298 seconds the transaction will cancel and not fully complete which will end up having broken references and access across the instance. We do have a solution to this: How to adjust granting of roles and groups to use background jobs instead of Foreground job. This will mean the session will not be locked and also the transaction will use background processing so can run for a long time without timing out which should fix your user/role issues. Otherwise you can deleted roles/groups using scripts and run them in scripts - background or fix scripts this will use background processing also which means no 298 second quota rule. Why does g_user.hasRoles return false for my users? g_user.hasRoles is returning false even if users have internal roles this is because the user has external roles also. If the user has roles like snc_external or sn_customerservice.customer combined with any other internal role like 'itil' it will still return false. This is because the instance considers that user external as they have an external role and therefore without a role. As documented here: https://docs.servicenow.com/bundle/rome-customer-service-management/page/administer/contextual-security/concept/explicit-roles-in-csm.html?cshalt=yes The hasRoles() method The hasRoles() method is still available, but is deprecated in the Geneva release. Use the hasRole(role name) method instead. If you do use the hasRoles() method, note these changes: This method automatically excludes the default snc_internal role when it checks for roles. This means that if a user has only the snc_internal role, the hasRoles() method still returns false.If the user has the snc_external role, the method returns false because the instance considers external users to be without a role. This behaviour is expected. snc_external or sn_customerservice.customer is a special role that is used to indicate a user is an external user. getRoles() for an external user always return false since by definition an external user has no role on an instance. My users are showing as sys_id and not the actual name? This is a result of the sys_user_role entry corresponding to the sys_id being deleted or otherwise missing from the instance. A number of causes exist: sys_user_role has been deleted, but is still present as a contained record in sys_user_role_contains or sys_group_has_role.The contained role (sys_group_has_role or sys_user_role_contains) have been removed, but the UI transaction has timed out, leaving behind orphaned sys_user_has_role records.sys_user_has_role has empty references, but it is not due to one of the above causes, or it is unclear why this empty reference exists. If this is due to the Cause 1 above, you can edit the parent group, or role, and remove the (empty) reference. The system will then remove the empty sys_user_has_role references.If this is due to the Cause 2, you can follow the instructions in How to adjust granting of roles and groups to use background jobs instead of Foreground job to ensure the UI transaction does not time out, and undo / redo the role or group change again.If it is not a contained role, but a directly granted role, it can be removed directly from sys_user_has_role.If this is not clear (cause 3), or you require further assistance or clarification, please raise a ServiceNOW technical support case. Reference: KB0781684 Why are roles showing as empty on tables like sys_user_has_role, sys_group_has_role and sys_user_role_contains? This is similar to the previous entry, because it is due to the sys_user_role record being deleted and the UI transaction has timed out, leaving broken references in the fields on sys_user_has_role (field: role), sys_group_has_role (field: role) and sys_user_role_contains (fields: role and contains). These can be removed by an admin user and can be easily located using the correct filters on these tables. A similar issue can occur with sys_user_grmember if a group has been removed and the transaction timed out. The records with the broken references no longer serve a purpose and should be removed as detailed in the referenced article below. Reference: KB0860107 What is the user: License.role.testing and why can we find a large number of deletes on sys_user_has_role daily in deleted records? Scheduled Item UA License Download [Daily] is part of the new Licensing Framework since Paris, which creates the temporary user [license.role.testing] for the PROD instance License Checking that is executed every 24 hours.The new Paris Licensing Framework creates a temporary user [license.role.testing] and assigns all the roles to this user for the PROD instance License Checking. Once the check has completed, it deletes this temporary user and all the associated records in [sys_user_has_role], once every 24 hours when this scheduled job is executed.For further information on this temporary user, please review KB0861074: What is the licensing.role.testing user and why is it on my instance? Why do i not have any security admin how can i get this role back? When the security admin role is installed it is linked to the system admin account. Some times this account is being deleted and then no other user has this role, and you can only be granted security admin from another user with that role. If you are in this situation then please raise a case with technical support and we will recover the admin account and grant it security admin role. We do have rules to stop deletion of users when a role is only assigned to that user, but still it happens and the role can go missing. Why is "Elevate Role" not working anymore? This is normally linked to an adjustment of the sys_user_role record for admin. check the admin role and check to see if elevated privilege is ticked. If it is this may cause unexpected behaviour For more information: Elevated privilege roles Warning:The use of elevated privilege on the admin role is not supported and may cause unexpected behavior. To require administrators to manually elevate, see Force administrators to manually elevate.