After installing or upgrading a custom scoped application onto a target instance, the Runtime Access Tracking field setting is automatically set to a value of Enforcing (and this value cannot be modified), despite the fact that the value of the Runtime Access Tracking value on the source instance is set to value other than Enforcing.

Runtime Access Tracking changed to Enforcing


Although not necessarily well documented, this modification of the Runtime Access Tracking field is actually the designed and expected behavior in the system.  The default system behavior is that, for any custom scoped application that has the value of the Runtime Access Tracking field set to Tracking on the source development instance, this value will automatically update to a value of Enforcing on any target instances to which it is installed.  The Runtime Access Tracking field is locked down on this Scoped Application record on the target instance and thus cannot be modified.

Thus, this expected behavior is for an application which at the time of publication, has the Runtime Access Tracking field set to a value of Tracking, this value will automatically be updated, on the target instance, to a value of Enforcing.  There is no warning that this will occur, so it may catch some administrators or users unawares when they notice this value has changed and the application might behave differently by default because of this change on the target instance.  At first, it may appear that the application did not install correctly, or in the case of an application upgrade did not actually upgrade as intended.  However, as noted, this is the default designed behavior for this field on an install or upgrade to a target instance and thus there should not be concerns regarding an invalid install or upgrade of the application.

The purpose of this system behavior is to help protect the scoped application, once published and installed on target instances, from being used in a manner not originally designed by the author of that application.  The author thus has control over his own application and prevents the application from interfacing with objects to which it was not intended and without that author's knowledge.

As this is the designed behavior for this field, it should first be understood how the system is designed to work.

The method for which the application has been designed to work is for the application designer to ensure that all the scripting functionality of the application is executed at least one time during testing.  In this way, any necessary Cross Scope Privilege records can be created on the test instance.  Then, when the application is published these Cross Scope Privilege records will be deployed with the application.  Any Cross-Scope privileges that are defined and se to allowed will be permitted, while any that are not defined (or implicitly set to deny) will not be permitted.  At such time as the scoped application is installed on a target instance, the expected and necessary Cross Scoping records are packaged and installed with it and the application will work as required on the target instance.

Thus, in the case that the Runtime Access Tracking record is set to Enforcing on the source instance, the usual procedure is for the developer to ensure that the necessary Cross-Scope Access records are created and in place before final publishing of the application.

The usual way to do this is for the developer to ensure that every potential script and functionality of the application was executed at least once as per the normal expected usage of the application.  This would then identify the necessary Cross-Scripting permissions that should be added to the application.  In the case in which the Runtime Access Tracking application is set to Tracking on the source during development, when any functionality occurs that requires cross-scraping permissions, an appropriate Cross-Scope scripting record is created which will allow this access.  In the case in which the application has the Runtime Access Tracking afield set to Enforcing, each access requiring these cross scope privileges will not be allowed but a record will be created in the Cross Scope Privileges table with a type of Requested.  The Developer would then review these records and determine if this operating requiring cross-scope access should be allowed, and may then either select Denied or Allowed as appropriate for the operation.

Important Note: After the application is published, unless the Runtime Tracking Access field is set to None, the system will only allow runtime requests to execute that have a valid cross-scope privilege record on the instance.

Resolution or Work-Arounds

As this is the actual expected and designed behavior for custom Scoped Applications on the instance, the best option is to ensure that the application, before publication, has all the necessary Cross Scope permissions required for proper operation of the application.  If not, the application and the cross-scope privileges should be corrected on the development environment and republished after which time it can be reloaded onto the target instances.

Alternatively, the Runtime Tracking Access field on the source instance application could be set to "None", the application republished, and then reinstalled with the newest version on the target instances.  However, this should only be done if this setting was inadvertent and these Cross Scope access controls at the scope level will not be needed for the application.  This is usually only recommended for scoped applications that might be specific to a small environment and not intended to be distributed to multiple environments or published to the ServiceNow Store.

 Setting Runtime Access Tracking to None

Additional Information

Much of the information discussed in this article was originally found in the following excellent blog post on the ServiceNow Community site (see the section titled Enabling Cross Scope Access):

Article Information

Last Updated:2019-08-02 20:59:53