IRM > Control > Control Indicator > Script

PeterP003464432
Tera Contributor

Hi Team,

 

with the help of a control indicator (ServiceNow IRM), I want to automate control testing.

 

I created a REST Message accessing an IAM Solution to get some data, this works perfectly in Scripts - Background and when executing the REST Message directly.

The script I'm using is the one from the HTTP-Method of the REST Message under Preview Script Usage. 

 

The problem I'm facing is, that this script will not be executed in a Control Indicator - it seems that it runs always in the catch-section of the script.

 

For your reference here is the script I'm using:

 

try {
var r = new sn_ws.GlideRESTMessageV2('GETAccessRoles', 'GET_Roles');

var response = r.execute();
var responseBody = response.getBody();
var httpStatus = response.getStatusCode();
result.passed = true;
result.value = 200; //just for troubleshooting
}
catch(ex) {
var message = ex.message;
result.passed = false;
result.value = 123; //just for troubleshooting 
}

 

Any ideas???? Thanks in advance !

1 REPLY 1

Matthew_13
Mega Sage

Hi Buddy,

This is a pretty common IRM / Control Indicator gotcha, and nothing is “wrong” with your REST call itself.

The key thing is that Control Indicators run in a different execution context than Background Scripts or the REST Message test UI. When something isn’t allowed in that context, ServiceNow throws an exception immediately — which is why your script always ends up in the catch.

A few likely causes that I can recommend:

  • The Preview Script Usage example often works in global/background, but Control Indicators are stricter. In many cases you need to use sn_ws.RESTMessageV2 instead of sn_ws.GlideRESTMessageV2.

  • Cross-scope access: the Control Indicator may not have permission to read the REST Message definition or use the credential/connection alias, even though it works as admin in background Scripts.

  • Outbound REST restrictions: the indicator runs as a system/evaluation user with fewer privileges than you expect.

Right now your catch hides the real error, so you’re flying blind. Log the exception so you can see what’s actually failing:

catch (ex) {
  gs.error('Control Indicator REST failed: ' + ex);
  result.passed = false;
  result.value = ex + '';
}

Then run the indicator and check System Logs. The error message will usually tell you exactly whats blocked cross-scope, credentials, API access etc....

Once you see that message, the fix is usually straightforward:

  • add a cross-scope privilege,

  • move or duplicate the REST Message into the same scope,

  • or adjust which RESTMessage class you’re using.

@PeterP003464432  - Please mark Accepted Solution and Thumbs Up if you found helpful