solving an Application Cross-Scope Access problem

[brianrichards]

Sometimes working with scoped apps gives me a headache.

My broad problem is that I frequently have to employ guesswork to solve cross scope access issues, and I find the documentation for using cross scope access records very limited. So to start, does anyone have a great approach for determining what should go into such a record? Or are there good sources on the web that discuss this bit of functionality. (Don't even bother posting the ServiceNow documentation link for this. I've already invested the five seconds it takes to learn all it has to offer.)

The specific problem I am having right now is this: I created a scoped app that includes a table extended from CMDB. As a temporary measure (I know, I know) I am using an on insert business rule to generate an Incident record for every scoped app record created. When such a record is created we see the following error message:

'Access to api 'put(incident.sys_id)' from scope 'x_camu_sw_asset' has been refused due to the api's cross-scope access policy'

Functionally each record (x_camu_sw_asset and the BR-generated incident) is created as expected, and the CI field on incident is updated as per the BR the way I expect. To ensure that this all happened I already created a cross scope access rule to permit stuff in my scope to write to incident. That made sense.

But this error is killing me. I assume that I need to create some other cross scope access rule for some scriptable, but I am at a loss to determine what it is that I need. And more importantly I am frustrated because I cannot generalize a troubleshooting process for when I stumble across something like this.

Any ideas?

Brian

[Pradeep Sharma]

Hello Brian,

Can you please share the exact script that you are using?

https://community.servicenow.com/community?id=community_blog&sys_id=44ad22a9dbd0dbc01dcaf3231f961921

Thanks,

Pradeep Sharma

[brianrichards]

The following is implemented as business rule on the table in scope 'after' 'insert'

(function executeRule(current, previous /*null when async*/) {

spawn_record();

function spawn_record() {
	
var dem = new GlideRecord('incident');
dem.contact_type = 'Web';
dem.u_category = '771dba496fc411001effeef11c3ee445'; //Request
dem.assignment_group = '87c5dd006f911100747ba14d5d3ee433';
dem.u_business_service = '1dbf690c135cea00f4fe7b104244b043';
dem.caller_id = current.contact;
dem.opened_by = current.contact;
dem.short_description = 'Additional Computer Lab Software Request for '+ current.name;	
dem.cmdb_ci = current.sys_id;	

var message = 'The following request was submitted via the Service Portal.\n\n';

message += 'Contact: ' + current.contact.getDisplayValue() + '\n';
message += 'Notify contact: ' + current.notify_contact + '\n';
message += '\n';
message += 'Software requested: ' + current.name + '\n';
message += 'Short description: ' + current.short_description + '\n';
message += 'Version: ' + current.version + '\n';
message += 'Platform(s): ' + current.platform.getDisplayValue() + '\n';
message += 'Publisher: ' + current.publisher + '\n';
message += 'Publisher website: ' + current.publisher_website + '\n';	
	
dem.description = message;
dem.sys_id = dem.insert();
	
}	
	
	

})(current, previous);

[Pradeep Sharma]

Thanks for the update. I was not able to reproduce this issue on my instance-Kingston release.

Can you please try to reproduce this error on personal dev instance so that I can take a look.

Thanks,

Pradeep Sharma

[brianrichards]

Yeah. Sure. It may take me a few days to port this work to a dev instance since we're talking about a complete custom application in my university's environment, but I'll try to pull some time away to rebuild at least a proof of concept on my PDI.

In the meantime, any thoughts on the bigger problem, which is that this stuff is just really poorly documented? Am I missing some source of information about cross scope access records?