Heiko Bllr
Tera Guru

Today when I looked at the table of scoped applications (sys_app) at one of my current clients I was a bit surprised. Because what I saw was, 61 custom scoped applications (17 of them global).

 

This client is just starting its ServiceNow journey (ITOM/ITSM is live and SPM will be live soon). And the overall guideline is to go OOTB...

 

In the last years I was involved in few CSM implementations as architect, here we created one scoped app for each use case (case type) and for one client we had created one generic app for the external user onboarding process, in support of more than one such CSM custom application.

So maybe I missed something during those past years and the world needs more scopes? Ok, now I became curious to see how my current two other large clients are doing:

 

Client A (uses ServiceNow since 2009): 3 scoped apps (1 global)

Client B (uses ServiceNow since 2013): 77 scoped apps (8 global)

 

Surprise again, or maybe not. The platform of client A is rather old, because many customizations were done before scoped apps became really available I suppose. And later they didn't really make use of scoped apps? Seems odd though.

Client B is quite large and complex as well, there are a lot of OOTB but also custom applications installed (created). Probably a reasonable number of scoped apps I would say over a period of roughly 9 years (scopes became available at around 2015/2016 afaik).

 

Looking at the names of the scoped apps of my client (the one that first surprised me), it seems that for any/some individual requirements a new scope was created (like for catalog items and some business logic behind) - why?

 

Let us think about, why scoped applications have been introduced. This article here is a good read: Background and Philosophy of Scoped Applications - ServiceNow Community

 

In my opinion, I would create a scoped app for following reasons:

  • Extending (!) an existing application with new (!) functionality
    • So if I need to add new functionality to the Service Request Catalog, let's create one app and not 8
  • Creating a new custom application
  • For clear segregation of data / duties purposes, even for administrators (think HR)
  • If you have to store your source code in a repository (Github, etc.)
  • If you need a new table and new roles

For configuring an existing application, let's say HRSD, for the following I would not create a new scope but use the existing SN scopes for my configurations:

  • Knowledge base configuration
  • Taxonomy
  • Catalog items
  • Portal pages

This could be a start. Unfortunately there is no guidance for that topic, so we need to define this kind of governance for our client's ServiceNow platforms ourselves.

 

Please use the buttons and comments below to provide feedback. I'd love to hear your opinion on that important topic.

2 Comments