Managing end user licenses usage through role assignment

[JE3]

Hi,

A few questions I'm hoping somebody here can answer.

1) I am wondering if there is a list of OOB roles with reference to what level of user licensing they incur when assigned to users?

2) What are the general guidelines for roles, global and custom app scope, in terms of license incurrence?

3) Is there an OOB role or could we create custom roles that are allowed to be assigned to all end users (i.e. CMS/SP only users) to control portal area access with roles, without incurring additional license cost?
The purpose for this would be to use the OOB functionality of giving access to components by role, rather than e.g. using a group and custom script.

Thank you.

// Jannick E

Added line spacing

[Allen Andreas · Accepted solution]

Hi,

You may have someone else come along that can speak to this but ultimately, you'd want to get with your sales rep.

We are about to go-live from Express to Enterprise at my company and I've asked this sort of thing before and it's best to have your rep explain things or look at your contract, etc.

Just throwing that out there!

[JE3]

Thanks,

Yeah I've spoke to our rep previously but I do realize it's hard to get a definitive answer.

My main concern is e.g. in a scenario of letting external users to the company enter a portal without roles and being able to differentiate company users imported from our AD for our company portal.

// Jannick E

[Chuck Tomasi]

hi Jannick,

When it comes to licensing, I decline to offer anything in the community as it changes over time and can be referenced later with inaccurate results. When it comes to licensing, work with your account team to understand what the impact is and what you can use "safely" without incurring additional costs to accomplish your goals.

[robpickering]

I agree with Chuck (does anyone disagree with Chuck?).

To answer your first question, no, the roles that grant access to applications OOB do not directly correspond to the licensing you have, because there are suites of applications that are often bundled together, but the roles themselves are more granular OOB as you may not want a user to have access to every application to which they are entitled via their license.

To answer your second question, see Chuck's answer.   You need to have this understanding with your Account team.

To answer your third question, I would offer that when I was a customer, we created custom roles that defined the license types that each user was being assigned.   So, we'd assign the appropriate ServiceNow role which granted the access to the application AND we'd grant the license type role for that user.   If a user had multiple licenses, we'd assign multiple custom roles to that user to represent each license type.     The "license" roles were never used to grant access to the applications, they were only used for auditing purposes.   We originally thought that building hierarchies would be a good idea, we were wrong, as there are too many permutations, so we settled on this method.

That way we could easily report on our custom roles and see our license counts.   Warning though, this requires some discipline and occasional auditing by your ServiceNow admin, but I found it worthwhile.   It also allows transparent conversations with your business because there's no gray areas about who is using what.   If they want to remove the access, we would also remove the custom role.

Your account team is the ultimate authority on your licensing, so work closely with them.

-Rob