Why Application Scope in ServiceNow Is Important

Since the Fuji release of ServiceNow, the platform introduced the concept of Scoped Applications.  This feature creates a private namespace assigned to a collection of tables and scripts and is very important for several reasons.

1. The Scope "holds" the records and acts as a container for the app

2. Scoping improves instance security by limiting what apps can do to other parts of ServiceNow

3. Scoped apps can be versioned and have a governed upgrade process

4. Scoped apps can be uninstalled easily without leaving code behind

 

Let's talk about why each point is important.

 

The Scope "holds" the records and acts as a container for the app.

First let's understand some historical context.  ServiceNow was originally built as the Glide development platform; a web-based tool to enable people to build applications.  Each application would consist of at least one table in a database and scripts that could manipulate the data.  There were also all sorts of development-oriented components built-in to construct full-featured applications, like UI elements, a graphical workflow engine and a content management system.  It was built as a development platform.  What Fred Luddy and the other founders actually built out to prove the value of the platform and go to market was a suite of IT Service management applications and the rest is history.

What was available from the beginning were features for each customer to add and build their own customizations into their instance.  You could not only change the default applications, such as adding a field or creating a new Business Rule script, you could make new tables and build completely new script logic around them.  That is, you could create a brand-new application.

The line between a customization and a new, separate application was blurry.  There was no definition of, "what is an app?".  Compounding the issue, is that ServiceNow has this amazing feature that allows you to create a new database table not from scratch, but by extending an existing table.  When you do this, the new table inherits all the properties and functions of the source table.  As new custom apps were built using extension tables, it became a challenge to determine what may be affecting business logic "upstream".

With the concept of application scoping, every element from the tables to the scripts starts with the same name.  These names are assigned by ServiceNow themselves and registered to avoid collisions.  In the case of apps from Stave, every part of every app we code begins with our vendor prefix, "x_stave_", and no other certified app builder can have that name.  Following that vendor prefix, all certified apps have a scoped application name.  In the case of the Stave Relationship Manager, the application name is "relmgr" and all components of that app begin with "x_stave_relmgr_".

Scoped_App_NS_2016-05-25_at_1.55.19_PM

This is a super easy, intuitive, human-readible way to know exactly what is in the app!  At a glance, it's easy to understand what tables, scripts, and more are associated with both a registered vendor and certified application.  We now have a much-better definition of, "what is an app?" in ServiceNow.

The screen shot below shows the manifest contents of the Stave Relationship Manager app.

 ScopedAppFiles-RelMgr.png

(You can see Relationship Manager in action, as a free trial in your instance here:)

Try Now on the Store

 

Scoping improves instance security by limiting what apps can do to other parts of ServiceNow 

With the inherent flexibility in ServiceNow and how easy it was to create things, it also became easy to build things with unintended consequences (or what you're users would call, "break things").  It was possible to include a line of code in a Business Rule that was for the Incident table, to affect something with data in the Change table.  Without knowing that and not having visibility into everything, those bugs became extremely elusive to track down.

Many of this issues are fixed with the introduction of scoped applications because without explicit permission, one scoped app may not interfere with another.  Developers must define any permissions their apps require involving other apps, and users are notified of these permissions before a scoped app is installed.

Here are the default permissions and security controls. 

ScopedAppAccessPermissions.png 

 

Scoped apps can be versioned and have a governed upgrade process

Improvements and changes to applications are going to happen.  In the past, developers would be required to manage and apply a sequence of Update Sets.  There was no control put in place and it was difficult to 

Scoped apps introduce versions and give developers the ability to name and track changes over time.  This version is displayed to end customers so they know what they have installed and any updates are displayed with a notification.  Instance administrators manually opt to install any upgrades in accordance with any change management processes in place.

Notice in the screen shot below, Stave FITARA Manager is on "Version 1.1.7" and no Updates are available for any apps this instance has entitlements for at this time.

AppVersions.png

 

Scoped apps can be uninstalled easily without leaving code behind

 As customers using ServiceNow grow, change, and expand so does their instance.  Cloud Governance and IT Controls is a discipline around this process and can fill volumes.  Previously, when a customer had a highly-configured instance, it was difficult to find the various components and business logic code in order to deactivate them.  With scoped apps, it's easy for customer admins to remove the entire scoped app.

Another great advantage to the ServiceNow platform's architecture is that while everything is stored in the underlying database, code and data are segregated.  This means that even if you uninstall a scoped app, it's possible to leave any user data in the instance for historic reporting, auditing, or just because you like hoarding data.

Such an example, might be a user storing Mean Time to Repair (MTTR) information in our Stave FacilitiesMAX application.  Should they ever remove the app, the MTTR data on equipment they had entered and managed in FacilitiesMAX can be retained within ServiceNow.

 

Going Forward

Scoped apps offer some tremendous advantages in the ServiceNow platform and the features will probably continue to increase.  I expect we'll start seeing more default applications defined with their own scope, and I expect many Professional Services organizations will create scopes for the customizations they create.  Every certified app available on the ServiceNow Store currently must also be scoped and as more apps are distributed through that marketplace, I believe developers understanding of benefits to scoped apps will increase.

If you have more questions about app scoping or the ServiceNow Store, put them in the comments below and I'll try to answer them.