How to fix cross-scope access policy : Security restriction issue?

[vimal11592]

Hi,

I have written business role in 'x_y_z'. In business rule I am calling third party application and trying to create some variable set using third party application data.

I used background script tool and came to know that I am facing following issue :

"Security restricted: Create operation against 'item_option_new_set' from scope 'x_y_z' has been refused due to the table's cross-scope access policy"

When I ean the same script in global scope.I am able to create variable set.In my application I have assigned admine and security admin role.

Can someone please help me How to fix the issue or some otherway to create application specific variable set .

Thanks

Vimal

[Chuck Tomasi]

Hi Verda,

To do that, you would need to add the cross scope permissions yourself to the table (see the related lists at the bottom of the table definition.) If you don't have the proper cross scope permissions added, the system will do it for you based on the table settings. That's what this message is telling you. "Hey, you asked for this so I'm letting you know that I'm adding it for you." It does it once and even adds it to the application's scope - so if you see this in dev, you know it is captured in the app files/update sets automatically so people don't see it in production.

[William49]

So, during an app dev course, I came across this, and I'm like, oh the system is creating cross scope privileges. But then, I thought, why is it doing this, I set the app access 'all other apps' and 'can read' only, yet other app scopes are able to update records on my app scope.

I don't know if the student lab instances are misconfigured or if I missed something but, on app scope a, setting accessible from to all app scopes, and only marking can read, a br created in another app scope (app scope b) that queries and updates app scope a, is having privileges auto added, and completing it's activites, which I think defeats the purpose of setting this setting in the first place ... 

[Chuck Tomasi]

They aren't misconfigured. They are just using the default setting from the app you created. There's a field on the sys_app table called Runtime Access Tracking that determines the behavior. By default it is set to tracking.

That says "I'm going to register these requests because you asked me to track them." All inter-scope calls get recognized - what the system does is based on the app that makes the call.

Runtime access tracking | ServiceNow Docs

[JV6]

Hey Chuck,

Whenever I try to change that option it doesn't save. Everything I save/ update it just returns to the previous option, which is This application scope only. 

For Reference I'm trying to change Risk Task (sn_risk_risk_task) application scope. I'm doing it within the Risk Application and the parent table Risk (sn_risk_risk) currently has it at All Application Scopes. 

[Chuck Tomasi]

If it's not saving properly, reach out to support. It sounds like there's something else at work that may be interfering.

HI Service Portal - ServiceNow

Contact Support | ServiceNow