Avoiding the ServiceNow Snowflake Problem - Roles, Users, Groups, Portals, Menus

Published On: 2021-02-09, Reading Time: 5 minutes

I have seen it countless times. The IT organization buys ServiceNow and then the rest of the org wants to use it. The biggest problem is the IT takes shortcuts and short term decisions that make it painful for the rest of the organization to adopt. This makes every instance a snowflake and reduces the chance for true organization adoption.

So how does one avoid taking these shortcuts? Let’s dive into some important tips to help make your instance scalable.

Tip #1: Setting up Roles

If you get nothing else from this, post - this is the most critical tip. Setting up roles correctly will provide you the most scalable solution. Roles are used in so many places in the system - it is the one thing you want to get right and have a solid process.

In ServiceNow, you assign permissions (ACLs) to roles and roles to groups and users to groups. So getting roles right (both creation and process) will save you pain down the road.

So role checklist:

  1. don’t modify out of box roles or add ACLs to them.
  2. Always create new roles and assign out of box roles as “contained roles”
  3. Assign ACLs to your created roles.
  4. For every user affiliation you have (ie: staff, faculty, doctor, patient, student, alumni, student worker, applicant, intern, etc) - create a special role for them and then apply out of box roles as contained roles - THIS IS CRITICAL

So why am I stressing so hard on roles?

Roles touch everything in the system. It touches the application navigator (sidebar), widgets, widget instances, portal pages, portals, knowledge bases, knowledge articles, flows, rest APIs, etc. If you assign out of box roles to manage this such as “itil” - you will find yourself in a use case where you need someone to have itil but not have access to the specific part (ie someone else in the org wants to use the tool - but not the IT stuff). I will probably make a few posts about specific industries and how to setup roles for success.

Tip #2: Setting up Users

Do you use local login or your company identity management solution?

When you first get a ServiceNow instance, you have your first decision point. This depends on two questions:

  1. How mature is your identity management practices?
    1. Do you have an On-Prem Active Directory (or alternative) or a cloud Active Directory (or alternative)?
    2. Do you have good affiliations/types/tags for your users?
    3. Do you have good onboarding practices to these identity management practices?
  2. How will your “customers” authenticate?
    1. Will they use the company identity management solution?
    2. Do they exist already in the company identity management solution?

If you are struggling to answer this question, you may want to start with local accounts and not try to scale your solution out to the organization. Bloating the user table is going to be painful by trying to “sync” users. Another alternative may be to only sync a subset of users (only sync the people who will use the system, you can always expand it in the future). If you can get a file feed of users instead of LDAP - that would be the way I go because it is more robust and dealing less with all the crappy data that is stored in LDAP.

Tip #3: Setting up Groups

Do you have an external system that manages groups that is easy to use for people?

Groups can be a nightmare to manage if done incorrectly. Groups are used in a lot of places in ServiceNow. I see people say “Just use the Active Directory groups”. I normally avoid this because it is painful to create them for the average user and they are rarely up to date. Unless you have a robust scalable group management system, I opt to using local groups in ServiceNow and manage it through catalog items. Make sure you setup group types as well. I recommend having the following: assignment (used to assign work to support teams), permission (used for access purposes only), resource (if you plan to use PPM)

Tip #4: Creating a Portal

The only rule of portals is NEVER USE Out of Box Portals or Widgets. ServiceNow is notorious to making changes to the portals and widgets and not telling you. This will make upgrading harder.

So what do you do? Clone widgets and Clone Portals before using them. You can always use the out of box portals as a reference point or after an upgrade to see new widget changes.

This tip may not be as relevant after Quebec+ because UI builder will soon become the defacto standard for Portal building.

Tip #5 - Menus / Application Navigator / UI Actions

The only rule of menus and UI actions is don’t use the out of box menus. This is another example of ServiceNow making changes and under the hood, not telling you. This one is a bit tougher because ServiceNow has A LOT of menus and ui actions.

So what can you do? You can insert and stay the menus you care about and set the old to require admin. This will cause them to show up in upgrades, but that is okay because it will also tell you if they changed anything else.

comments powered by Disqus