Every ServiceNow application has its own application scope that determines which of its resources are available to all the other parts of the system. There are two types of application scopes – global scope and private application scope (also known as scoped apps). In other words, a scope is something like a namespace for your application that separates your UI components, tables, and classes from everyone else’s. With more control over your application and how it can be accessed, the scope keeps the code from accidentally polluting the global namespace.
Benefits of Scoped Apps
Enabling governance and versioning
Scoped apps gave developers the ability to name and track changes over time. They introduced versions which have different functions. For example, a version can be displayed to end customers to let them know what they have installed and display a notification if there are any updates. Administrators need to opt to install updates manually and do it in accordance with change management processes.
Improved instance security
ServiceNow brought flexibility and made it easy to create applications. However, it made breaking things a lot easier, too. It made it possible to include a simple line of code intended for one table, but that affected something with data in another table. Scoped applications were introduced to fix these issues because one scoped app cannot interfere with another one without explicit permission. Any permissions that apps require involving other apps must be defined by its developers. Before a scoped app is installed, users are notified of those permissions.
Uninstalling scoped apps without leaving any code behind
Organizations using ServiceNow change and grow, and so do their instances. In the past, if you had a highly-configured instance, it was difficult to find a business logic code or components to deactivate them. However, customer admins are now able to remove the entire scoped app because the code and data are segregated. Therefore, it is possible to leave user data (for auditing, historical reporting, etc.) even if you uninstall a scoped app.
Scoped apps act as containers
In ServiceNow’s beginnings, the line between a new (separate) application and customization was blurry because what is considered a new, separate app wasn’t clearly defined. ServiceNow enabled users to extend an existing table to create a new database which inherits the source table’s properties and functions. However, determining what may be affecting the system upstream became a challenge with building apps with these extension tables. With the scoped apps concept, we now have every element (from the tables to the scripts) starting with the same name. ServiceNow assigns and registers these names so no other certified app build can have that name, which helps avoid collisions.
When Should We Use Scoped Apps?
When considering the application scope, there are 2 use cases:
- Creating a custom app from scratch
- Extending an existing app
When creating a new app from scratch, you should always go for creating it as a scoped app because ServiceNow wants to make it easier for customers to deploy apps and simplify future upgrades. What scoped apps also make simpler is to back out changes.
If you are making changes (modifying or extending) to a global scope application that will affect other applications, you should leave it in the global scope. On the other hand, if those changes will have a minimal impact on other apps, then you can make the changes as a scoped app. Once you build a scoped app or an app in global scope, it is not recommended to move from one to another, and there’s no tool available for performing this migration automatically.
As ServiceNow experts with years of experience, we can provide assistance and training with building scoped apps in Service Now. Feel free to ask questions on Twitter or call us.