Scope provides protection for application resources on the ServiceNow® platform. It controls what an application is allowed to interact with and can disallow access from other applications. When you create an application in Studio, it will be in a scope.
Global scope
As an administrator, you are working within a scope upon login. By default, if nothing else has been specified, you should be in the Global scope. But if you last worked in another scope, you will be in that scope upon login.
Global scope is intended for applications and functions that should be widely available to users or other applications on your instance. Basic tables and workflow for things like incidents and problems, for example, are in the Global scope.
Scoped Applications
Administrators are encouraged to build applications in their own scope and not in the Global scope. These applications are referred to as “scoped” applications. Since you can open up Studio and see all the items you need within the selected scope, this can make development work easier to manage. There may be some applications or work that need to be global, but make sure it is justified – for instance if you are modifying an Incident form, that would be done in the Global scope in which it exists. See our article on the Benefits of Scoped Apps and When to Use Them.
How to tell what Scope you’re in
Core UI (UI16): Administrators can make the Application/scope display in their title bar by selecting System Settings (the gear icon) to open the Settings window.
Click the “Developer” setting, and toggle right on “Show application picker in header.” (As done in this screenshot, you might want to toggle right on the update set picker.) You could use the Application dropdown to pick the Application (scope) from here, but it is more convenient to have it in the title bar.
The scope shows in the title bar and is easily selectable.
Next Experience: In the Next Experience, scope is not shown directly in the title bar, but it displays when the cursor hovers over the bar’s small globe icon, or the globe is clicked.
Click the globe to see scope, which you can expand to switch scopes.
You can filter the scope list. Click on a scope to switch to using it.
A red ring shows around the globe if the scope is not Global (or if the default update set is not in use). If the red ring is not present, you are in the Global scope and using the default Global update set.
Be Aware of Scope
With that brief overview of scope, here are some things to keep in mind. Some of these can be confusing if you’re not aware of how scope works:
- Work in Studio when you can. Doing application work in Studio will put you in the application’s scope, which will help you avoid some of the situations mentioned below.
- Check scope before making changes, so you don’t have to re-do the changes in the proper scope. This goes right along with making sure you are in the correct update set, as well.
- Do not ignore messages about scope. Otherwise, you might be allowing two applications to talk to each other when you did not intend them to be linked, or you may have parts of what you intended to be in one application separated into another.
- Consider scope when troubleshooting. Sometimes the code is correct, and it appears something “should” be working but is not. It could be that you’re running code in the wrong scope.
- You may not always be alerted to being in the wrong scope. Many screens warn if you’re in the wrong scope to be able to make an update, but there are a couple of places where you might not see any scope message onscreen:
- Opening up a “Form Design” view in the wrong scope:
You might expect a warning to appear, such as what would be given on the Form Layout view, but there is not one. If the Form Design doesn’t allow you to edit or move fields, it is likely because you need to switch to the form’s scope.
Editable view
Read-only view – but the differences can seem subtle. The section header is grayed out, there are no field edit gears, and the “Field Types” selection tab is missing.
A big hint you’re in the wrong scope is that an attempt to drag a field from the Fields tab turns the form background pink, and you cannot place the field.
In contrast, the “Form Layout” page will display a warning message when you are in the wrong scope.
- When attempting to create a new UI Policy, Business Rule, etc., for a table when you are not in its scope:
When you open a new window to create a business rule, etc., you might find that the table on which you want to place it is not available in the dropdown Table menu. That probably means you are in the wrong scope to work with the table you want to use.
By contrast, opening an existing business rule will give a warning if you are not in its scope.
Allowing interaction between apps
While this article will not go into detail, there are ways to enable applications in different scopes to talk to each other.
You may have seen a message as an Administrator asking if you want to grant a “cross-scope” privilege. You can view entries of privileges granted in the “Application Cross-Scope Access” module in the Navigator.
Tables also have a field that indicates whether they are allowed to be “accessible from” only their application scope, or from all application scopes. Script Includes and Workflows have this setting as well.
The Custom Application Settings (File > Settings) record in Studio also has settings that can help secure or open access. Additionally, if you are familiar with using “Events,” you can use them to communicate between applications.
See the documentation for more information on how to use these configurations. It may be good to know that you can grant something like a cross-scope privilege before you decide that placing an application in the Global scope is necessary.
