Skip navigation

Developer Community

4 Posts authored by: Pradeep Sharma Employee

While developing a scoped application, you may want to secure scoped applications against other applications. Securing application helps the author to have control of their application and prevents customers from interacting with any other artifacts without the author's knowledge. Below are the ways in which design time permissions on the scoped application can be granted or restricted.

 

3 ways to secure your application

  1. Application Access Setting
  2. Cross Scope Access
  3. Restrict Table Choices

 

In this post, I will show you how to utilize Cross Scope Access, Application access setting and Restrict Table Choices to secure your scoped apps against other applications. I'll give you examples of how to use Application Access Setting, Restrict Table Choices, Cross Scope Access to enable access, disable access, and track your scoped apps across the platform.

 

Application Access Setting

Application Access Setting is defined to specify what application artifacts are available to other custom applications in different application scopes. These permissions are in addition to the standard access controls (ACLs) that determine whether users can access data in the custom application.

 

  1. On your instance navigate to System Applications > Studio
  2. Click on open Studio tab.
  3. Click on the application and then select the tables whose application access setting needs to be modified. You will see the below image once you click on any table.

scoped application access.jpg

The Can read, Can write, Can update, and Can delete Application Access options, grant scripts from other application scopes the ability to perform database operations against the table records. In the default case, all application scope scripts can read the table’s records but cannot perform any other database operations.

 

 

"Allow configuration" restricts whether out-of-scope applications can create application files like Business rules, New fields, Client script and UI actions.

 

Restrict application on a scoped app

I can restrict other applications from doing any operation (Create, Read, Update, Delete, Web Service Interaction) on this scoped app by selecting the "Accessible from" value to “This application scope only.” Other application can only interact when the value is set to  "All application scopes.” Depending on the requirement and the use case, you can select all or either on this checkbox to grant permission for other applications.

 

For other artifacts like Script Include, access is granted or restricted depending on the value set on “Accessible from” field. This field defines whether a script is public or private.

 

Making a script public

A public script is a script available to all applications. To make a script public, set the "accessible from" field on the Script Include  to all application scopes. Any changes to a public script include must be done carefully to prevent breaking applications that depend on it.

 

Making a script private

A private script is a script which is specific to the application which it is defined.To make a script private and inaccessible from other applications, set the "Accessible from" field to This application scope only. This allows the script to be called only by code within the defined application scope and prevents code in other application scopes from accessing the script. By setting scripts to private, application developers can easily modify or refactor scripts in future versions since no other applications depend on it.

 

Example of creating a Record in a Group Table:

 

Application access settings are different on each OOTB tables. For example, the default Group table allows another application scope Web Service access and Read access. However, other permissions are restricted. If a script attempts to perform an operation that is not allowed, admin users see a message:

Execute operation on API 'GlideRecord.insert' from scope 'CSA' was denied. The application 'CSA' must declare a cross scope access privilege. Please contact the application author to update their privilege requests.

Evaluator: com.glide.script.fencing.CrossScopeAccessNotAllowedException: Access to GlideRecord.insert from scope x_13241_csa not allowed

In the above case, "Can Create" checkbox has to be set to true to be able to create the records in Group table.

 

 

Example of making a call to JSUtill from a scoped application:

 

In the below screenshot we can see JSUtil cannot be called from any other application as the accessible value OOTB is set to "This application scope only".

jsutill scoped app.jpg

In the above case, accessible from has to be changed to "All application scope" to ensure JSUtill works across applications.

 

Please be aware any changes made on global artifacts will be in the global update set.

 

Please work out with ServiceNow Certification Team in case you have modified the application access setting (Global or base system tables) and the app is intended to be submitted to store. We will approve or reject apps on the store based on the application use case. The same case applies to any modification made (Accessible From value) on base system artifacts like script include.

Cross Scope Access

Cross scope access allows administrators to manage out-of-scope access to application resources by creating a list of operations and runtime privileges that the application authorizes to run on the target instance. A cross scope is applicable only if the author of the app sets the Runtime access value to Tracking or Enforcing. This helps the author to have control on their application and prevents customers from interacting with any other artifacts without the author's knowledge once the app is downloaded on the target instances.

 

Cross-scope privileges can be granted for:

  • Table: Read, write, create, delete records
  • Script Include: Execute API
  • Scriptable (script objects): Execute API

 

Enabling Cross Scope Access

  1. On your instance navigate to System Applications > Studio
  2. Click on application i.e for ex : CSA ( This is the custom application I have created on my instance)

    create scope access.jpg

  3. Open the File menu and select the Settings menu item. The default value for the Runtime Access Tracking field is set to Tracking.

    scoped app tracking.jpg

 

  • None: All cross scope privileges are granted automatically at runtime.
  • Tracking: Allows application scripts to access resources from other applications. A record for the access is automatically inserted in the cross-scope access table with a Status value of Allowed. This is the default setting.
  • Enforcing: Allows application scripts to access resources from other applications only after an admin authorizes the access. A record is automatically added to the cross-scope access table with a Status value of Requested.

 

A custom application which have "runtime access " set to tracking will be changed to enforced automatically during app installation on the target instance.

 

During testing, application developers should run all of their application scripting logic to ensure the system creates any necessary cross-scope privilege records. After application publication, the system only allows runtime requests to run that have a valid cross-scope privilege record.

 

Example of across access scoped application:

 

Let’s assume I have a business rule on the custom table which creates a record on Incident table. To make this app work on other instance, I as an author should ensure that this script is at least once executed on my dev instance. You will see an entry in cross scope table as soon as this script is executed on dev instance before the app is published.

 

Here we are assuming Runtime Access Tracking is set to Enforcing.

var gr = new GlideRecord('incident');
gr.initialize();
gr.short_description = 'This is a test for CSA';
gr.insert();

 

When the script executes, ServiceNow checks to see if the cross-scope access between the CSA scope and the Global scope table is allowed. In this case, it is not because the Enforcing setting requires an admin to authorize the access. This is a snippet of the error from the System Log:

Security restricted: Execute operation on API 'GlideRecord.insert' from scope 'CSA' was denied. The application 'CSA' must declare a cross scope access privilege. Please contact the application author to update their privilege requests.

Evaluator: com.glide.script.fencing.CrossScopeAccessNotAllowedException: Access to GlideRecord.insert from scope x_13241_csa not allowed

 

  1. Open the Application Cross-Scope Access module by navigating to System Application> Application Cross-Scope Access
  2. Search for all records with a Status field value of Requested
  3. To grant access, an admin user must click the Open record icon to open the record for editing.
  4. Change the Status to Allowed then click the Update button.

access cross scope app.jpg

The above case is only when the author chose to set runtime access to enforcing. By default, runtime access is set to tracking on the application and at runtime, cross scope privilege records are automatically granted access.

 

 

Restrict Table Choices in a scoped application

To get to Restrict Table Choices, follow the same steps 1, 2 and 3 as mentioned in cross scope section above. Restrict Table Choices application sets limits on an application file configuration to only tables from the current application. This setting can be defined at each application level. By default, the checkbox is set to false. You can set the value to true depending on your app requirements.

 

Example of restricting table choices:

 

Let’s assume I have set Restrict table choice checkbox to true. In that case, we can only select tables which are in the same scope. This will be true for any artifact created in scoped app for ex: Client script, UI Policy Etc.

restrict table choices.jpg

 

We have successfully covered how Cross Access Tracking manages out-of-scope access to application resources, Application Access restricts database operations, and Restrict Table Choices application to limit application files configuration. Utilizing Cross Scope and Application Access Setting are key components of scoped applications and its success.

 

For additional help on this topic, see what other customers have asked:

cross scope privileges denied by table cross scope

Cross scope privilege issue in Scoped Application

access to api refused

Scoped apps - can I allow scripted read access to global scope without allowing creation of business rules, too?

- Pradeep Sharma (@sharma_pradeep)
ServiceNow

PS: Hit like, Helpful or Correct depending on the impact of the response

If any scoped application developed depends on a plugin then that is tracked as part of dependency.  Dependency is a must for scoped applications that are submitted to the ServiceNow store. This is to ensure that customers who purchase the scoped application are aware of all the prerequisite plugins to be installed prior to installing the app on their instance. In this blog, I will talk about when a dependency is tracked automatically in a scoped application and steps to capture dependencies manually

 

How to automatically track plugin dependencies

The system can automatically identify and add dependencies on the plugin when you:

  • Extend a table
  • Add a field to a table
  • Call a script include

 

For example, let's assume I have activated "Facilities Service Management" plugin on my instance. As part of my scoped app use case, I need to create a custom table "Now Fac Space" and extend it from the OOTB table "Facility Space" (the table which was created when we activated FSM plugin).

 

  1. Create a custom table "Now Fac Space" and extended from Facility Space

    create custom table.jpg

  2. Navigate to System Application>Application>Click on Edit button under application "Now application" and check for related list "Dependencies"

    dependencies.jpg

You will note the dependency on the plugin "Facilities Service Management" is automatically tracked and is captured as part of dependency list in scoped app "Now application". The reason the dependency is tracked automatically here is because we extended an OOTB table which belongs to "Facilities Service Management" plugin.

 

How to capture Plugin Dependencies manually

The system cannot identify dependencies on client-side resources such as UI-based JavaScript libraries. In such cases, you must manually add the dependency. Below are the steps to be followed to add dependency manually.

 

For example, let's assume I have to capture the "orchestration" plugin dependency manually in my scoped app "Now application".

 

  1. On your instance navigate to System Applications>Studio
  2. Click on open Studio tab.

    Studio+servicenow.jpg

  3. Now select one of the applications from the list (for example, Now application)

    code+search+application.jpg

  4. Click on File>Settings.

    Screen Shot 2017-04-25 at 2.04.56 PM.png

  5. From the Dependencies related list, click Edit and select the exact dependency from the left slush bucket and move it to right and save the form. For ex: added "Orchestration" plugin as a dependency.

    dependencies related list.jpg

 

Wooo we have successfully added "Orchestration" plugin as a dependency in scoped application. There will be message warning on the screen with the name of the prerequisite plugin to be installed when the customer tries to install this application on his instance.

 

Global dependency is not captured as a dependency in any application because global artifacts can be created by the user on any instance manually

 

The same steps apply in case a manual dependency is to be captured on any scoped application.

 

We have successfully covered how a dependency is tracked automatically and how to capture dependency manually in scoped application. If any scoped application intended to be published on the store and has a dependency on plugins, vendors have to make sure that all required plugins are captured as part of dependencies in scoped application. This is to ensure that customers who purchase the application from the store are aware of all the prerequisite plugin before installing the app on their instance.

- Pradeep Sharma (@sharma_pradeep)
ServiceNow

PS: Hit like, Helpful or Correct depending on the impact of the response

ServiceNow has developed a utility called “code search” which helps to search a code both within and outside of your application. This is helpful whenever you’re troubleshooting or just trying to understand how something works. Code search is built into the ServiceNow Studio IDE interface to make developers life easier. Search can be easily applied without navigating to the platform UI by applying additional filters using Code Search. Code search is offered in the Geneva release onwards. I will walk you through an example of how to find a particular line of script/fields and where it is being used in the system

 

Example of how to use code search

Let’s assume as part of my troubleshooting, I want to investigate what all scripts are triggered against a field for ex: close_notes which set the field to be mandatory. Here are the steps to be followed.

  1. On your instance navigate to System Applications>Studio
  2. Click on open Studio tab.

    Studio servicenow.jpg

  3. Now select one of the applications from the list (for example, Now application)

    code search application.jpg

  4. Now on upper right corner, you will see the “Code search” button.

    code search servicenow.png

  5. Click on Code Search.
  6. Enter the search for ex: close_notes.
  7. Now you have the option to either select a table to search from or search in all application.
  8. Select one of those options and hit search button.
  9. The output result will be the name of the script(hyperlink) with code line number in case a match is found.

    output result.jpg

As you can see, we have all of the scripts which are triggered against the field close_notes. In this particular case, it's most likely a client script/UI action/UI Policy which is responsible for the mandatory operation. Now I can go through all the scripts found to understand the behavior further.

 

Tables included in code search scanning:

Below is the list of tables on which scan is performed whenever a user enters a keyword to search for. For ex: In the above case we have searched for a field "close_notes".

  • Access Control
  • Business Rule
  • Client Script
  • Email Template
  • Inbound Email Action
  • Map Page
  • Notification
  • Processor
  • Relationship
  • Scheduled Script Execution
  • Script Action
  • Script Include
  • Style
  • Table Transform Map
  • UI Action
  • UI Macro
  • UI Page
  • UI Policy
  • UI Script

 

Please note the scan will be across global and scoped applications.

 

Code Search presents a powerful tool to developers. This is really helpful to find a particular script during active development in their instance. This allows the developer to search scripts across the platform, rather than doing the limited search on the individual table by applying a filter i.e business rules, client script, UI scripts, etc.

 

For more information on code search see:

Is there a way to make Studio's Code Search into a favorite or module?

What's New in Geneva for Developers?

- Pradeep Sharma (@sharma_pradeep)
ServiceNow

PS: Hit like, Helpful or Correct depending on the impact of the response

UI16 is the latest UI, included started in Geneva. UI16 provides usability improvements and design changes, including an enhanced application navigator, color themes, and a refreshed knowledge base that delivers a more modern style to help drive user efficiency and productivity.That means if you just received your instance from ServiceNow and it is running on Geneva, you do not need to activate the plugin to get UI16, because it is active OOB. For instances upgrading from a lower version (pre-Geneva), you will need to activate the UI16 plugin (com.glide.ui.ui16) manually. As long as you have the admin role, activating UI16 after upgrading to Geneva or newer version, is a breeze.

 

Before you begin hunting around for the plugin to activate, confirm that you have successfully completed the upgrade of your instance by visiting the upgrade monitor (System Diagnostics > Upgrade Monitor).  When your upgrade is complete, it will display statistics on the most recent upgrade, including start and end date and a green message will appear saying it was a success.

upgrade success.jpg

 

To activate UI16 in your upgraded instance

  1. Navigate to System Definition>Plugins.

    search plugin.jpg

  2. Search for UI16 plugin (com.glide.ui16)

    UI16 plugin.jpg

  3. Open the plugin record.
  4. Click on related link "Activate/Upgrade"
  5. Click Activate to activate the plugin.
  6. Click on "Close and Reload Form" once you see the success message popup.
  7. Click the gear icon in the banner frame to open the System Settings window.
  8. Click "Switch to UI16"

    switch to ui16.jpg

 

Just to emphasize, after you have enabled the plugin, you must also complete step 8! Which means after enabling, you must tell your instance to "Switch to UI16" or you will continue to see UI15. If you do not see the ability to switch between UIs and the  "Switch to UI16" button is not available see ServiceNow KB: The "Switch to UI16" button is not visible (KB0564468)

 

Switching between UI15 and UI16

After UI16 is activated, you may need to view the changes in both versions of user interface. You can switch to UI15 while in UI16 by clicking on the gear icon in the banner frame. Please note, that by default, "Switch to UI15" button is only visible to the admin. However, if you would like to make this button available for other users, you can add a system property to configure other roles to see the "Switch to UI15" button.

 

Switching from UI16 to legacy UIs

If you wish to switch back to a legacy UI, I'm talking pre-UI15, you will first need to switch from UI16 to UI15, then you can switch to UI11. Unfortunately, there is no direct way to switch from UI16 to a legacy UI without, first, switching to UI15.

 

Congratulations, you have successfully activated UI16 plugin on your instance!

 

 

----

 

 

Here are some of the highlights from the UI16 overhaul:

 

Flexibility in the Application Navigator:

  • The Application Navigator is now completely collapsible into the “edge.” Use this feature when you need more screen real estate to focus on the tasks at hand.
  • Three-column structure to help you find what you need, when you need it. Columns include the standard application and module display, your favorites with new icons, and a new history log displaying recent interactions.

 

Improved Personalized Settings and Connect Access:

  • User options are updated to include user profile, Connect sidebar (Chat functionality), search, help, and baseline system settings.
  • The user profiles now feature global user presence. Whenever a user is online, a green dot will appear on their avatar. This applies for your profile and any other user profile in your instance to help communicate your status to team members. You’ll see this functionality appear in activity streams, live feeds, and Connect conversations.
  • Navigate to the settings to choose an instance color theme, language, time zone, list and form appearance. In addition you can set Connect notifications preferences based on personal preference.
  • Automatically jump to your latest conversation or activities in the Connect sidebar.

 

For more details on why UI16 is cool see Navigating the updates in UI16.

 

 

For additional help on activating UI16, see what other customers have asked:

UI16 plugin status can't be changed to "Active".

Can I enable UI16 but make UI15 default for all users in Geneva?

I upgraded to the Geneva instance and received and email saying the upgrade is complete, but it still appears to be Fuji?

Can we enable UI16 after upgrading to Geneva?

- Pradeep Sharma (@sharma_pradeep)
ServiceNow

PS: Hit like, Helpful or Correct depending on the impact of the response

Filter Blog

By date: By tag: