"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

Michael Jones - · ‎01-26-2021

I believe that you need to have allow configuration checked as well for you to be able to run a script against the table. The other permissions are for users in the UI. Give that a try.

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!

Pablo Lopez · ‎01-26-2021

Hey Michael! Thank you for responding.

I did do a query in my script and originally I double checked by printing gr.getDisplayValue() with gs.info. So I'm 100% sure this is an existing record.

I tried changing "Allow Configuration" to true, but it still restricts write operations from Global scope.

Michael Jones - · ‎01-26-2021

Actually, are you adding a query to your gr call? If not, then you would be creating a new record rather than updating an existing one. Try adding a query (so that you have a target record) or otherwise add a create cross-scope privilege record and see if that works.

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!

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!