"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

Pablo Lopez · ‎01-29-2021

Thank you Michael and creativethinker for your responses! So as it turns out, it kinda just worked after leaving it be for a few days. I didn't change anything from what is shown here but now I actually have cross scope write access. I find that quite mysterious, but it seems like I'm not the only one with these kinds of problems.

In any case, this is solved!

Report Inappropriate Content · ‎02-09-2022

I know this is an older post but it comes up in google searches. In regards to the problem resolving itself, I have found that there is a caching issue that can be remediated by running the following:

GlideTableManager.invalidateTable(<table_name>);
GlideCacheManager.flushTable(<table_name>;

Michael Jones - · ‎02-09-2022

Thanks for sharing! I did come across something similar as well, related to deploying changes between instances where similar settings did not take effect - I hadn't considered it might resolve the same thing in the source system so certainly worth looking into!

Here is what I'm referring to:

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0695145

Thanks for sharing!

Michael Jones - Proud member of the GlideFast Consulting Team!

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

jnskender · ‎12-13-2022

This fixed my issue as well. This should be the accepted answer.

Michael Gedzelm · ‎08-16-2023

Thank you! Not sure who you are because the author of the post is showing as "Not applicable", but these two lines of background script code fixed my problem. I was at it for hours. I added cross-scope privileges, restricted caller access privileges, ACLs, Caller Tracking, etc. All that was necessary for me was going to the table definition, checking the "Can Update" under application access, and then running the two lines of code to clear the cache.