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...

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...

Chapter 1, ServiceNow Foundations,  introduced the foundations of ServiceNow. One of the most fundamental parts of an application is how it stores its data, and we saw how virtually everything you see and do in the platform is stored in the database.

Specifically, ServiceNow is built on a relational database. Instances hosted by ServiceNow use MySQL, a popular open source database that is robust, well featured, and scalable. These kinds of relational databases are relatively simple to understand, which is one of the reasons they are most commonly used: data is held in tables and columns, and relationships may exist between rows.

Another type of relationship between records is many-to-many. The relationship between siblings is many-to-many. I can have many brothers and sisters, as can they. But how can I store this information? A reference field can only point to one record.

Adding a lot of reference fields into a form is one way. I could create as many reference fields as I have siblings. However, that's not great design. What if another brother or sister were born? Making new fields every time a new baby arrives is not cool.

Instead, we could create another table that sits in between two records, acting as the "glue" that sticks them together. This many-to-many table has two reference fields, each pointing to a different side of the relationship.

In the hotel application, we want to take reservations for our guests. Each reservation might be for more than one person, and each person might have more than one reservation. This sounds like the perfect use for a many-to-many...