Why does the "sn_hr_core.manager" Role grant the "catalog_admin" Role?

[Will West1]

Does anyone know the process reason or technical reason that "sn_hr_core.manager" Role grants "catalog_admin"? These users can create, edit, and delete Catalog Items and User Criteria directly in the production environment which seems risky. This is not constrained to HR Catalog Items but allows these users to create, edit, and delete all Catalog Items including ITSM, WSD, GRC, CSM, etc.

I can understand a highly controlled Role such as "sn_hr_core.admin" granting "catalog_admin" but do not know why the more general "sn_hr_core.manager" Role would need this access and, if they do, why it does not grant a safer Role such as "catalog_editor".

Also, since "catalog_admin" grants "user_criteria_admin", they are also able to create, edit, and delete User Criteria. The result is that a "sn_hr_core.manager" working on Knowledge has a high chance of clicking "New" instead of "Edit" (since they now see a "New" button) resulting in duplicative and/or non-efficiently scripted User Criteria (resulting in performance issues) or modification to existing User Criteria that then impacts other users and the Portal.

The Components installed with Case and Knowledge Management ServiceNow Docs simply states that "sn_hr_core.manager":

Grants access to all HR cases, profiles, secure information.

[Hemanth M1]

Hi @Will West1 ,

That's correct, the "sn_hr_core.manager" role inherits the "catalog_admin" role. I would recommend adding an extra layer of ACLs around the user criteria table to restrict write/create access for users with the "sn_hr_core.manager" role.

Removing the "catalog_admin" role from this list is not ideal because users with the "sn_hr_core.admin" role will not inherit the "catalog_admin" role.

[PrashantLearnIT]

Hi @Will West1 

You can remove catalog_admin role from the inherited list of roles under sn_hr_core.manager role

[Will West1]

Hello @PrashantLearnIT,
Thanks for the response. I know I can remove the Role but, given how risky this Role is, I presume ServiceNow added this Role for a purpose and want to know what process and/or technical impact it will have to how the HR Managers work before changing it. Do we know what that reason is? Hemanth M1 also correctly points out that "sn_hr_core.admin" grants "sn_hr_core.manager" that grants "catlaog_admin" and, if this is removed, "sn_hr_core.admin" will no longer have "catalog_admin"... unless we subsequently add "catalog_admin" to ""sn_hr_core.admin".

Hello @Hemanth M1
We are attempting to avoid customization and creating ACLs to restrict "user_criteria_admin" from creating, editing, deleting User Criteria under certain conditions is counterintuitive. Typically "catalog_admin" do need access to User Criteria to help develop Catalogs. And, to be honest, their ability to create, edit, delete any Catalog Item in any Catalog directly in production has me more worried that User Criteria. Do we know why ServiceNow believes HR Managers need to be able to make changes to Catalog and User Criteria directly to the production environment across all the modules?

[Hemanth M1]

Hi @Will West1 ,

It's tricky to say why ServiceNow has assigned the "catalog_admin" role to "sn_hr_core.manager." Even if they would like to have access to HR catalog items, they could have just restricted access there. We may need to ask ServiceNow for better clarity!!!

However, To tailor this to your scenario, you can remove the "catalog_admin" role from the "sn_hr_core.manager" and add it under "sn_hr_core.admin" (so that it only inherits for HR admins). Then, test thoroughly with different personas.

And if you think the HR manager needs to have the "catalog_admin" role, you can grant it ad hoc.

Hope this helps!