Since the Fuji release of ServiceNow in March 2015, the platform introduced the concept of Scoped Applications. This feature creates a private namespace assigned to a collection of tables and scripts. This functionality has been a boon to the ServiceNow ecosystem.
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 originally built 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.
1. Scoped Applications on ServiceNow act as containers
The line between a customization and a new, separate application was blurry in the beginning. There were no clear definitions or rules for what is considered a new separate app. Compounding the issue, is that ServiceNow allows you to create a new database table 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 these 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 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. So, Stave’s scoped application naming convention is:
This convention allows you to see what’s 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.
The screen shot below shows the manifest contents of the Stave Cybersecurity Manager app.
{{cta(’93ecbf3f-37f5-4eed-8fe7-3dcc3376e06f’,’justifycenter’)}}
2. Scoping APPS IN SERVICENOW improves instance security
With the inherent flexibility in ServiceNow and how easy it was to create things, it also became easy to break things. For example, it was possible to include a line of code in a Business Rule that was for the Incident table that affected something with data in the Change table.
These 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.
3. Scoping enables versioning and governance
Scoped apps introduced versions and gave 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, Cybersecurity Manager is on Version 3.5.2 and no Updates are available for any apps this instance has entitlements for at this time.
4. ServiceNow Scoped apps can be uninstalled easily without leaving code behind
As customers using ServiceNow grow, change, and expand so do their instances. 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.
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.
{{cta(‘c329ce9c-b30c-4798-a2dd-5ff9e6e637c6′,’justifycenter’)}}
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.
