Set Values is not updating the associated record to it when running in different Application Scope (Stop Processing not working in Scoped Inbound Actions)DescriptionSet Values can not determine the record to update when run in a different Application scope to the record it's supposed to be updating. A common symptom of this is that attempts to use the event.state = "stop_processing" line in an Inbound Email Action (Inbound Action) script to stop processing of further Inbound Actions will fail. Lines like this might be seen in the log files: 2020-06-22 18:22:29 (618) worker.0 worker.0 txid=f859fff1db71 EMAIL.085b2b20db61dc10fa9ea2b4449619c3: Inbound Email Action [Decision Rules - incident] - [stop_processing]2020-06-22 18:22:29 (619) worker.0 worker.0 txid=f859fff1db71 EMAIL.085b2b20db61dc10fa9ea2b4449619c3: Inbound Email Action [Decision Rules - incident] - Event [queued.1bc97110db111010cc7ac6fc349619bd]2020-06-22 18:22:29 (620) worker.0 worker.0 txid=f859fff1db71 WARNING *** WARNING *** Security restricted: Access to api 'put(sysevent.state)' from scope 'x_customer_app1' has been refused due to the api's cross-scope access policy2020-06-22 18:22:29 (620) worker.0 worker.0 txid=f859fff1db71 EMAIL.085b2b20db61dc10fa9ea2b4449619c3: Inbound Email Action [Decision Rules - incident] - Event [queued.1bc97110db111010cc7ac6fc349619bd]2020-06-22 18:22:29 (621) worker.0 worker.0 txid=f859fff1db71 EMAIL.085b2b20db61dc10fa9ea2b4449619c3: Decision Rules - incident : did not create or update incident using currentRelease or EnvironmentMadrid Patch 5 and newer ServiceNow releasesCauseTighter restrictions on scripts running scopes from the London release onwardsResolutionThis can be achieved in either of these two ways: 1) Enable System Property: glide.record.legacy_cross_scope_access_policy_in_script to True. Doing this will resolve the particular issue with the event.state = "stop_processing" line in an Inbound Email Action that's detailed above. The purpose of the System Property is: Legacy behavior provided create/update access to tables that did not allow so. In order to prevent legacy customers from having applications broken when this behavior was patched we created the 'glide.record.legacy_cross_scope_access_policy_in_script' GlideProperty which, when true, causes this function to fall back on legacy behavior.2) Check the Table configuration of 'Custom Table' Here in the Application Access section, Can Read, Can create and Can update should all be checked.