Jochen Geist
ServiceNow Employee
ServiceNow Employee

While the Now Platform platform delivers a lot of great processes out of the box, it's often required to tailor those processes to specific business needs. 

For a holistic view of Customization Best Practices, I can only recommend the Success Workbook: Business-smart customization.

In case a Global Scope Applications like Incident Management needs to be modified, this is usually done by just directly updating the objects in question. However, by utilising Global Scope App developers are able to

  • easier to keep track of what has been changed on the platform for each process or use case
  • use the Studio UI for development
  • unlock Source Control capabilities via git
  • make deployment easier by moving away from Update Sets

Example Use Case: Incident Closure

To show how a Global Scope App could be utilised for tailoring the process of closing an Incident, let's assume we have these 3 requirements:

  • The Incident should be closed after 5 days in "Resolved" state instead of 7
  • When an Incident is closed, a comment should be made to the Incident
  • The "Resolution Information" section should show the date and time when the Incident was closed

Creating the Global Scope Application

Global Applications can only be created via Studio, not with App Engine Studio.

When opening Studio, the dialog to create a new Application in Studio also offers the option to create the Application in Global Scope:

find_real_file.png

After the App is created, it's now selectable via Studio:

find_real_file.png

In case the option is not visible, please ensure you have a system property "sn_g_app_creator.allow_global" with the value of "true" defined in your instance.

Adding Files

Global Scope Apps extend the concept of Application Files by allowing them to be claimed by an App. It's also possible to "unclaim" Files or move them between Apps.

In Studio, existing Files from Global Scope can be added via "File ->Add Existing Files".

So first we have to add the autoclose threshold property to our application which can be done by searching for it's name:

find_real_file.png
find_real_file.png

We even get a nice warning that this file has not been customized yet:

find_real_file.png

Let's now add the "incident autoclose" Business Rule to our App as well.

By searching via Table "Incident" and then filtering on Business Rules, we can find the object as well:

find_real_file.png

Now the Property and Business Rule are both available in Studio and can be modified:

find_real_file.png

The highlighted line has now been updated to add a comment to the Incident when it's automatically closed by the system.

Finally we add the Incident Form to our App as well to change the "Resolution Information" section as required:

find_real_file.png

(Optional) Linking to Source Control

If desired, the changes can also be easily stored in git to unlock Source Control capabilities on them.

A summary of the benefits of Source Control can be found here.

find_real_file.png

Cautionary Tale: Working outside of Studio

Even with the property enabled, ServiceNow allows to modify global objects outside of Studio as well.

However even if the Global Scoped App is selected as the current Application Scope, a modification of a baseline object does not add it to the Application Scope.

It stays in Global Scope instead of being "claimed" by the Global Scope App.

"Claiming" objects in Global Scope is besides Studio only possible via the List Action "Move to Application":

find_real_file.png find_real_file.png

So remember to always first add the baseline objects to your Application Scope before editing them.

This does not not apply to creating new objects, these are always created directly in the Global Scope App.

Optionally you can also create an Update Set to capture your global changes and then add the objects via the Update Set filter:

find_real_file.png
Deployment Management

To move your changes to the Test and Production instances, Update Sets can be used as before.

It's also possible to have multiple Update Sets across different scopes together in an Update Set Batch.

However since these objects are now inside a Scope, we can also use the Application Repository to publish the Incident Management Application and then install it on Test and Production via the Repository.

Migrating to Global Scope Apps

In case certain processes have been customized already, it is also possible to retroactively move the objects into Global Scope Apps.

The easiest way is to do this either via the Update Set search or via the Table filter. As objects can only be claimed once, it is not a problem if multiple versions of those exists in multiple Update Sets.

10 Comments