Runtime Access Tracking / Cross-Scope Access / Caller Access
What does the "Runtime Access Tracking" property indicate? And where is it found?
It indicates whether or not you, as the Application's Author or System Administrator, care about "Tracking" the "Access" that is granted at "Runtime" to the resources outside the application that your application may attempt to utilize. That access could be to the Global scope or to another Application Scope. Tracking access involves creating a single record for each resource for which there is at least one access attempt, and whether or not that access was (or should be in the future) Allowed or Denied. The "Runtime Access Tracking" property is found in the main record for each Custom Application (table sys_app) in the section "Design and Runtime".
What does the "Caller Access" property indicate? And where is it found?
Caller Access is a property on each Script Include and on each Table that indicates whether or not you, as the Application Author, wish to Track/Allow/Deny "access" from outside "caller" applications to that specific resource. The purpose of this concept is to protect the scoped application, once published and installed on target instances, from being used in a manner not originally designed by the author of the application. The author thus has control over his own application and may prevent other application scopes from interfacing with certain objects without the author's knowledge.
What types of Objects or Resources are tracked?
Tables, Script Include Files, and "Scriptable" objects (objects which may be extended by writing scripts) such as the GlideRecord API.
What happens when I set the "Runtime Access Tracking" property to a value of "None"?
This means that you do not care about tracking the runtime access of externally scoped resources that your application accesses. Nothing will be done at the application level to block such access attempts. They will all succeed (if allowed by the target) and no record will be created about what has been accessed.
What happens when I set the "Runtime Access Tracking" property to a value of "Tracking"?
This means that you DO care about tracking runtime access to external resources accessed by your application.
- When your application attempts to access the resources in an external application scope, the "privilege" of doings so is tracked:
Table: sys_scope_privilege (Cross Scope Privileges)
Status: Allowed
What happens when I set the "Runtime Access Tracking" property to a value of "Enforcing"?
This means that you DO care about tracking, and also enforcing (allowing or denying) the access of runtime calls out of your application.
- Again, when your application attempts to access the resources in an external application scope, the "privilege" of doings so is tracked:
Table: sys_scope_privilege (Cross Scope Privileges)
Status: Requested
Initially, the record will be given a status of "Requested", and the access attempt will FAIL. Once the status of the record is manually changed by a System Administrator to "Allowed" then subsequent access attempts to the resource will succeed. Or, if the status of the record is changed to "Denied" then of course subsequent access attempts will continue to fail.
What happens when I set the "Caller Access" property or a specific resource to a value of "None"?
This means that you do not care about tracking or managing the runtime access from externally scoped applications to a specific resource (table or script include file). Nothing will be done to block such access attempts. They will all succeed, and no record will be created about what has been accessed.
What happens when I set the "Caller Access" property of a specific resource to a value of "Caller Tracking"?
This means that you DO care about tracking runtime access from external caller applications to the resource.
- When an external "caller" application attempts to access the resource, the "access privilege" is tracked::
Table: sys_restricted_caller_access (Restricted Caller Access Privileges)
Status: Allowed
What happens when I set the "Caller Access" property of a specific resource to a value of "Caller Restriction"?
This means that you DO care about tracking runtime access from external caller applications to the resource.
- When an external "caller" application attempts to access the resource, the "access privilege" is tracked:
Table: sys_restricted_caller_access (Restricted Caller Access Privileges)
Status: Requested
Initially, the record will be given a status of "Requested", and the access attempt will FAIL. Once the status of the record is manually changed by a System Administrator to "Allowed" then subsequent access attempts to the resource will succeed. Or, if the status of the record is changed to "Denied" then of course subsequent access attempts will continue to fail.
Related Articles / Resources / Videos
Video 1 of 4: Application Access Settings
Video 2 of 4: Runtime Access Tracking (AKA Cross-Scope Access)
Video 3 of 4: Restrict Table Choices
Video 4 of 4: Restricted Caller Access Settings (sadly, does not exist, or I can't find it)
Runtime Access Tracking (Developer site)
Runtime Access Tracking automatically changes to Enforcing after installation of custom application ... (Knowledge Article)
- Note that any "Runtime Access Tracking" value set to "Tracking" will be automatically changed to a value of "Enforcing" when an application is published and installed. The application designer should 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 will be created. 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 set to allowed will be permitted, while any that are not defined (or explicitly set to deny) will not be permitted. When the scoped application is installed on a target instance, the Cross Scoping records are packaged and installed with it and the application will work as required on the target instance. In this way, application authors can manually create cross-scope privilege records in advance to communicate which cross-scope resources they expect other developers to access.
Screenshots
Application Property:
Script Include:
Table:
Example Scenarios
- Please mark as Helpful if this article helped you. If information contained herein is incorrect, please do speak up.
Runtime Access Tracking / Cross-Scope Access / Caller Access
What does the "Runtime Access Tracking" property indicate? And where is it found?
It indicates whether or not you, as the Application's Author or System Administrator, care about "Tracking" the "Access" that is granted at "Runtime" to the resources outside the application that your application may attempt to utilize. That access could be to the Global scope or to another Application Scope. Tracking access involves creating a single record for each resource for which there is at least one access attempt, and whether or not that access was (or should be in the future) Allowed or Denied. The "Runtime Access Tracking" property is found in the main record for each Custom Application (table sys_app) in the section "Design and Runtime".
What does the "Caller Access" property indicate? And where is it found?
Caller Access is a property on each Script Include and on each Table that indicates whether or not you, as the Application Author, wish to Track/Allow/Deny "access" from outside "caller" applications to that specific resource. The purpose of this concept is to protect the scoped application, once published and installed on target instances, from being used in a manner not originally designed by the author of the application. The author thus has control over his own application and may prevent other application scopes from interfacing with certain objects without the author's knowledge.
What types of Objects or Resources are tracked?
Tables, Script Include Files, and "Scriptable" objects (objects which may be extended by writing scripts) such as the GlideRecord API.
What happens when I set the "Runtime Access Tracking" property to a value of "None"?
This means that you do not care about tracking the runtime access of externally scoped resources that your application accesses. Nothing will be done at the application level to block such access attempts. They will all succeed (if allowed by the target) and no record will be created about what has been accessed.
What happens when I set the "Runtime Access Tracking" property to a value of "Tracking"?
This means that you DO care about tracking runtime access to external resources accessed by your application.
- When your application attempts to access the resources in an external application scope, the "privilege" of doings so is tracked:
Table: sys_scope_privilege (Cross Scope Privileges)
Status: Allowed
What happens when I set the "Runtime Access Tracking" property to a value of "Enforcing"?
This means that you DO care about tracking, and also enforcing (allowing or denying) the access of runtime calls out of your application.
- Again, when your application attempts to access the resources in an external application scope, the "privilege" of doings so is tracked:
Table: sys_scope_privilege (Cross Scope Privileges)
Status: Requested
Initially, the record will be given a status of "Requested", and the access attempt will FAIL. Once the status of the record is manually changed by a System Administrator to "Allowed" then subsequent access attempts to the resource will succeed. Or, if the status of the record is changed to "Denied" then of course subsequent access attempts will continue to fail.
What happens when I set the "Caller Access" property or a specific resource to a value of "None"?
This means that you do not care about tracking or managing the runtime access from externally scoped applications to a specific resource (table or script include file). Nothing will be done to block such access attempts. They will all succeed, and no record will be created about what has been accessed.
What happens when I set the "Caller Access" property of a specific resource to a value of "Caller Tracking"?
This means that you DO care about tracking runtime access from external caller applications to the resource.
- When an external "caller" application attempts to access the resource, the "access privilege" is tracked::
Table: sys_restricted_caller_access (Restricted Caller Access Privileges)
Status: Allowed
What happens when I set the "Caller Access" property of a specific resource to a value of "Caller Restriction"?
This means that you DO care about tracking runtime access from external caller applications to the resource.
- When an external "caller" application attempts to access the resource, the "access privilege" is tracked:
Table: sys_restricted_caller_access (Restricted Caller Access Privileges)
Status: Requested
Initially, the record will be given a status of "Requested", and the access attempt will FAIL. Once the status of the record is manually changed by a System Administrator to "Allowed" then subsequent access attempts to the resource will succeed. Or, if the status of the record is changed to "Denied" then of course subsequent access attempts will continue to fail.
Related Articles / Resources / Videos
Video 1 of 4: Application Access Settings
Video 2 of 4: Runtime Access Tracking (AKA Cross-Scope Access)
Video 3 of 4: Restrict Table Choices
Video 4 of 4: Restricted Caller Access Settings (sadly, does not exist, or I can't find it)
Runtime Access Tracking (Developer site)
Runtime Access Tracking automatically changes to Enforcing after installation of custom application ... (Knowledge Article)
- Note that any "Runtime Access Tracking" value set to "Tracking" will be automatically changed to a value of "Enforcing" when an application is published and installed. The application designer should 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 will be created. 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 set to allowed will be permitted, while any that are not defined (or explicitly set to deny) will not be permitted. When the scoped application is installed on a target instance, the Cross Scoping records are packaged and installed with it and the application will work as required on the target instance. In this way, application authors can manually create cross-scope privilege records in advance to communicate which cross-scope resources they expect other developers to access.
Screenshots
Application Property:
Script Include:
Table:
Example Scenarios
- Please mark as Helpful if this article helped you. If information contained herein is incorrect, please do speak up.
