Scoping out limits

Running multiple applications on the ServiceNow platform brings benefits of scale. You may have IT using it to organize production issues, HR may perform case management, while the maintenance team use it to track leaky taps-each using separate, specialist applications that are built for their use. Since you are using a single platform, it makes it possible to share some data.

The Users table is a great example of this. While each department will want to control the privileges that each person has (someone from the facilities team probably shouldn't have access to all the payroll data), sharing the core data means there is one place to go and update. If you change your name, isn't it nice to do it on one system, without relying on complex integrations to simulate a cohesive system?

The diagram below represents how many applications all need to reply upon shared resources, like the user table.

Also, you often want applications to talk to each other. Consider that a new employee is joining Gardiner Hotels. As part of HR's "onboarding" process, several activities need to take place: the employee needs to be given an ID badge, undergo some training, get issued a mobile phone, and more. Each of these activities may be handled by different teams: HR might ask IT to provide the new employee with the phone, while the Facilities Maintenance team could create ID badges. Having the HR application automatically interface with the IT app saves time and increases productivity by eliminating double typing and miscommunication.

But this level of integration also causes challenges. The HR application can contain sensitive data-how do you ensure the IT app doesn't access it? The HR team needs to know that the rules and policies in place can't be circumvented, that another app doesn't have free access. And what exactly is in the HR app? Applications scope separate functionality, at both a naming level, and to provide extra security.

Separating by name

The previous chapter discussed how sys_id is the unique identifier for the majority of items you build. This lets you have multiple records that otherwise look identical-while people will get confused, the system will cope just fine with having 500 groups with the same name.

But some things are referred to by name, especially in code. A few notable examples are tables, roles and Script Includes (discussed in Chapter 3, Server-Side Control). It would be very cumbersome to refer to the Check-in table in a script as 84fc62b1eb111200e744e08a5206fee8 in order to ensure the right one is identified. And just by looking at the sys_id, you have no idea which application that table is part of.

So, for items that can be accessed across many applications, the platform uses a slightly more user-friendly system of scope names. This uniquely identifies your configuration, and makes ownership very obvious.

The scope name is made up of two parts-a vendor prefix and the application name:

• The vendor prefix is generated when the instance is created. It cannot be chosen. It is shared across all the instances of a customer. If you are using a developer instance, you will have a vendor prefix that looks like x_69373.

  Note

  It is called the vendor prefix because it shows who created the application. In Chapter 10, Packaging with Applications, Update Sets, and Upgrades, we see how applications can be downloaded from the ServiceNow App Store.

• The application name is specified when the application is created. We chose hotel in the previous chapter.

The two are joined with underscores (<vendor>_<app>), and every time an application is created, it is registered with a central ServiceNow repository to ensure uniqueness.

This scope name is then used as the prefix for many configuration elements, including the real table name (<vendor>_<app>_<table>), role (<vendor>_<app>.<role>), and Script Includes (<vendor>_<app>.<name>).

By including the scope in the name of these items, we ensure that there will never be two tables named the same, even if apps are shared over many different instances.

Seeing the scope

As you start exploring the platform, you will often see notices that you are editing configuration that belongs to another application, especially the global application. Unless you take ownership of that configuration and put it into your current application (often not a good idea, since it is global so everyone has access), you would need to switch scope to make the changes.

The global application is where most ServiceNow functionality lies. It means there are no scope controls, and all applications can use it.

To see this in action, follow these steps:

1. Close Studio (if open) and using the standard interface, and click on the settings menu (the cog icon, top right of the screen).
2. Switch to the Developer tab, and toggle on the Show application picker in header option. Once done, close the dialog. You should see that the application picker is now available in the interface.
3. Navigate to System Properties > System. You should receive a message saying you are in the wrong scope, and that all of the properties are read-only.
   
4. Using the application picker, switch to global. The properties page should refresh. The message should have gone, and the properties will be editable. If you wanted to switch temporarily, just for that just, you can click the link in the message. This would not change what application those elements belonged to however.
5. Once done, ensure you switch back into the Hotel application.

Note the consequences of this: by switching temporarily to global, you will be not be associating your work with the application you are building.

Moving between applications

Whilst you can move items between applications, it is typically not a good idea. It is a bad idea if you move items from global to an application, and a really bad idea if you move global platform functionality to an application.

Note

If, nonetheless, you mistakenly create a record and it is associated with the wrong application, use the Move to application... option in the Additional actions menu.

Moving configuration into an application means it'll be treated as part of that application. Any protection mechanisms (as discussed in the next section) will start to apply. This means that other apps that were dependent upon it may break. For example, if a piece of shared data that was used by both HR and IT is moved into the HR app, the IT application may not be able to access it any longer. The protection mechanism available to applications are discussed in the next section.

Tip

Additionally, as discussed in Chapter 10, Packaging with Applications, Update Sets, and Upgrades applications can be uninstalled. If you move platform functionality into an application, and then uninstall it, bad things could happen. Don't do it!