"Write operation from scope 'rhino.global' has been refused due to the table's cross-scope access policy" error even though everything seems to be configured correctly

Pablo Lopez · ‎01-26-2021

Recently I've been working on adding Activity Streams to our Scoped Application's Service Portal, and though I have been able to add activity streams to all relevant tables whether extended from Task or not, I am getting the following error when I try to post Work Notes or Additional Comments to the Activity Stream.

I have double checked that the tables in question have the correct Application Access. Here's a screenshot of how they look.

I also added a Restricted Access Privilege record and a Cross-scope privilege record in hopes that they'd help, but they did not.

According to multiple community posts this configuration should be correct, but it's still giving me the same error. In fact, when I try to write to our Scoped App's tables from the Global scope using the Scripts Background, I get the same error.

Has anyone encountered this error? Hopefully I just missed something or other. Thanks everyone!

Michael Jones - · ‎01-26-2021

I've occasionally run into stumbling blocks like this and the strangest part is that they can seemingly solve themselves, which is frustrating. I've found a couple of odd things that might be worth checking.

In the actual records for your cross-scope privileges, click on the 3-bars and select show latest update and make sure that the actual update is in the application scope (the record may show the scope but the update something else). If they're in global you may need to delete them and create them again.

Sometimes deleting and recreating the cross scope records fixes things even when the update is in the correct scope.

I've also, very rarely, found strange issues go away when you publish the app to an update set - I kind of chalk that up to coincidence more than fact however.

Last, but not least, a possible work-around: you can try creating a script include in your own scope that performs the operation you are trying to do, and then call it from the global scope. I've had some success using that approach.

Sorry for the false leads!

I hope this helps!

If this was helpful or correct, please be kind and remember to click appropriately!

Michael Jones - Proud member of the CloudPires team

I hope this helps!
Michael D. Jones
Proud member of the GlideFast Consulting Team!

View solution in original post

Harshal Nirmal · ‎07-05-2024

I don't understand your troubleshooting step

Harshal Nirmal

Ct111 · ‎01-26-2021

I think you need to create a correct cross privelge record inorder to rectify this issue. I would recommend have a look at any oob one and take reference from it and create once again.... And in that table screenshot which you posted can you crosschk if you are getting any option for Caller Access field rather than "None"... Mark my ANSWER as CORRECT and HELPFUL if it helps

deepu · ‎07-29-2021

Hi,

Follow the below steps to solve the above issue

1. Navigate to System Definition > Tables

2. Open the record for the custom table.

3. In the Application Access section, check the box for 'Can create' , 'Can update'

I hope this helps!

Please mark helpful if this answers your question.

Thanks,

Deepu R.

Julian Hoch1 · ‎09-14-2022

We had this same issue, and together with ServiceNow support figured out it was a caching issue.

Running

gs.invalidateCache();

in the background should solve it.

craigh1 · ‎01-30-2023

I've found this to be an instance cache issue - running gs.invalidateCache(); in a background script has resolved it for me