Application scope (creep?)

[Heiko Bllr]

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.

[Fred Jean]

Hello, I agree we would need more guidance from ServiceNow on that.
When "extending" applications such as HAM or HRSD, we often wonder whether we would do this in the related OotB scope or in a new custom scope. See my post about this here : https://www.servicenow.com/community/servicenow-ai-platform-forum/what-is-the-best-practice-around-s...
And talking about about HRSD, it really feels like there too many scopes involved, we often have to work on 3 or more different scopes to achieve one simple configuration. I wish we had some kind of scope hierarchy to make things easier somehow.

Now for the reasons to create a scoped one, one possible reason is also when building some customisation that seems generic enough to be reusable and provide value on other instances (although it may look may be too small to see it as an "application" first).

[Heiko Bllr]

When I think "Application Scope", following comes to my mind:

The first thing what ServicenNow asks if you create a new scope, is a table and a role. If you don't have that, you don't have an application and hence no new scope need. Also just a rough idea or guidance and it does not always apply - for example if you create new integration(s) to some external system, you might wanna create a scope for it (like ServiceNow does for each spoke) - but would you need a new table for that? Not really, unless you build something really complex.