Enforcing the separation

Consider your ServiceNow applications as a room (or floor) within a building (what an original metaphor, right?). While open-plan living is sometimes an advantage, it doesn't afford much privacy. Sometimes you want a door (and lock) to stop people wandering in and out of your room.

The ServiceNow platform gives you control. It acts as the application's doorman, deciding what comes in and what can go out. We'll see that there are many ways to be specific about how apps can affect each other. This is especially important when you install apps you haven't developed yourself.

Whenever the platform performs an action, it checks to see if it crosses a scope boundary. If a script was run in an IT scope, it will have access to all the tables and data that belong to the IT app. But it may not have access to data in the HR scope. The scope acts as the containing bubble; if all the elements have the same scope, it's fine. But the doorman will intervene if it crosses the boundary.

Tip

Much of the functionality delivered with the ServiceNow platform (for example, the ITSM applications) are not actually held within an application, but are associated with Global. This is not an application per se, but the absence of one. Functionality in Global is like being in the living room. It's fair game for everyone-no control.

Taking control of your application

ServiceNow provides three key features to control what and who comes in and out of the application bubble:

• Delegated Development can grant users special privileges to work with your application - but only with this app. You can, for example, give a user the ability to create reports for the Hotel application, but unless you grant other (perhaps global) privileges, the user won't be able to create reports for another.
• Scoped Administration (to be renamed Local Administration) restricts global administrators from accessing the application. Typically, if you have the System Administrator (admin) role, you have access to everything on the instance. With Scoped Administration, this may no longer be the case. Scoped Administration is discussed more in Chapter 8, Securing Applications and Data.
• Application Access controls how multiple applications work together. The two controls above work with users; Application Access lets you decide if the functionality of one application (in particular, the data structure) should be shared with others. Normally, a script running on the instance will have full access to the database, as we'll see in the next few chapters. Application Access controls that.

Delegating to developers

To build applications in ServiceNow, you've usually needed to give a user the admin role. As discussed in Chapter 8, Securing Applications and Data, the admin role gives System Administrative abilities; you get access to the whole instance, and all the global configuration available to it. That's a lot of power, if you only need to build a single app!

Delegated Development allows a user to get privileges to edit specific parts of a single application. This stops the need for granting powerful, system wide permissions to many users, giving much better separation of duties.

To see how it works, follow these steps.

1. Firstly, identify a test user who currently doesn't have any development permissions. Ross Spurger in the demo data is a great choice.
2. Let's use a feature we'll learn about more in Chapter 8, Securing Applications and Data, impersonation. Impersonation allows us to login in as that user, without knowing their password. In the standard interface, open the user menu (click your name, top left) and choose Impersonate User.
   
3. In the selection box, choose Ross Spurger. The interface will refresh, you can now interact with ServiceNow as this user. Note that the only options in the left menu are Self-Service and Collaborate.
   
4. Finish your impersonation by using the User menu and clicking Impersonate User again. Pick your admin user (likely to be System Administrator).
5. Let's give Ross the capability to edit the Hotel app. Open up Studio by navigating to System Applications > Studio, then click Go in the Open Studio section.
6. Select Hotel from the Applications list.
7. From the File menu, click Manage Developers.
8. In the Developers filter box, select Ross Spurger. The options you can grant to Ross are shown in the right pane.
9. Toggle on All File Types, and click Save.
   
10. To see what this change has resulted in, close Studio, and impersonate Ross Spurger again by repeating steps 2 and 3.
11. Immediately, you can see that there are many more options available to Ross. Navigate to System Definition > Tables.
12. As a global administrator, you would see over 2000 tables. As Ross, you would see only two: Check-in and Rooms. Those are the only two tables that are associated with the Hotel application.

    Tip

    The product documentation explains the different developer permissions that are available: https://docs.servicenow.com/bundle/helsinki-application-development/page/build/applications/task/t_AddADeveloper.html.

13. End your impersonation by repeating step 4, so you are back as the normal System Administrator.

Allowing other applications access

Having two applications working together can be quite nonintuitive, so I'll use an extended example. Consider that HR has built a wonderful custom application for their use. It stores information about every employee at Gardiner Hotels, in an employee profile table. There are several fields containing information, such as whether they are a contractor, permanent employee, or intern. It's kept up to date by the HR team.

This type of data is really useful for other departments, too. So, the HR team has added lots of security rules (discussed in Chapter 8, Securing Applications and Data ) to control sensitive information.

The facilities team wants to leverage this regularly updated data source and record what assets an employee has. The latest mobile technology is used at Gardiner Hotels, and some employees like it so much, they want to keep using it even when they leave the company. The facilities team doesn't really like this!

To help with this, the facilities team proposes to add a field to the employee profile table. It might store the serial number of the device, so the facilities teams knows which employee has which device. Even though this table is associated with the HR app, facilities wants its configuration as part of their own app so that they can control and update it.

Tip

This split control is key to the scenario. In this example, the facilities team is relying upon the HR employee profile table but also wants to add some functionality to their own app that they look after.

If the HR team wants to let this happen (and therefore have their data structure changed), they would tick the Allow configuration checkbox in the Table record. This lets other applications add to the table. (Navigate to System Definition > Tables to see the option,)

Tip

Note that although you can add fields to the table, you cannot change the default form. That belongs to HR. The facilities team could create a new view, or the HR team would still need to add the field to the default form. The facilities team, though, could control other items, like choice-list options.

Controlling application access

As you might have seen from the screenshot above, there are more ways to control what other apps can do. The starting point of Application Access is the Accessible from option:

• This application scope means that no other application can affect this table. Use this when you don't want to share any data at all.
• All application scopes lets you be more granular. This default option then lets you specify exactly what those applications can do.

The first four options (Can read, Can create, Can update, and Can delete) affect scripting. Every application can includes code that may attempt to interact with any tables in the database; these controls stop that. By default, Can read is checked, meaning scripts can look at data, but do nothing else. Allow access to this table via web services pretty much works as you think: if it's checked, outside systems can connect and work with the data, as long as they follow the right security rules (Chapter 7, Exchanging Data – Import Sets, Web Services, and other Integrations,  and Chapter 8, Securing Applications and Data provide much more information on web services and security rules).

Tip

These options work at runtime, or when the application is being used. The platform ensures that these rules are enforced, so a HR application can ensure that their data is secure, as they need to.

Restricting your choices during development

In addition to controlling the ability of other apps to interact, you can also decide what you (and your application) can see and do. One option is to reduce the selection of tables shown within the platform.

Whilst that may sound not very useful, it can help you from making mistakes. For example, it guides you away from building configuration that is dependent on others applications. To turn this option on, open up Studio, use the File menu and select Settings. The Restrict Table Choices option can be toggled on there.

The application settings record also stores about how your application interacts with others. By default, the instance notices what you are working with, and if it is using functionality outside of your application, it is recorded.

When you were making the Relationships in Chapter 1, ServiceNow Foundations, you may have noticed the following message:

And if you look at the bottom of the Hotel application settings, you will see this recorded:

The cross scope privileges list tells you what functionality stored outside of your app that your application is using. In this case, ScopedGlideRecord (used in the code of the relationship, and explored in much more detail in the next chapter) is flagged, with a status of allowed. Of course, you can review this list and decide not to grant access privileges. By default, cross scope access is recorded and allowed; you can turn this around by changing the Runtime Access Tracking to Enforcing.

If you did decide to revoke the access of ScopedGlideRecord, the Rooms on the same floor Related List would not work properly any longer. Specifically, you would get an error message when you visited the Room form, and you would see all the rooms across all floors.