workflows - branched IF conditions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-10-2016 03:14 AM
I previously had this working from the mini-lab https://community.servicenow.com/community/develop/blog/2015/10/18/mini-lab-workflows--playing-with-...
On a different project now and I want to employ the same again...
I am struggling to get the Condition to pay attention to the results in the script??
The script as follows:
activity = ifScript();
function ifScript() {
var result = {VALUE1:false,VALUE2:false, VALUE3:false, VALUE4:false};
if (VariableFieldValue == 'true') {
result.VALUE1 = true;
}
result.VALUE2 = true;
result.VALUE3 = 'true';
return result;
}
I have 4 conditions for the IF statement branches,
and so on...
I have also included some logs in the script and can see that the result.VALUEs are being updated, so it seems I am accessing the values incorrectly in the conditions to catch the output flows
when i had it without activity.result and just result.VALUE (no activity.) it was throwing an unbound or wrapped exception on result
- Labels:
-
Service Catalog
-
Workflow

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-10-2016 03:34 AM
Then this is a use case for using Branch and Join. I dont see the need for IF block still.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-10-2016 03:55 AM
I felt it would be tidier on the canvas and more concise to read.
What are your thoughts on the general use case for the subject of the Mini-Lab then? (Previously I had 12 lines which could fire. Currently I have 4 but this could change.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-18-2016 01:38 PM
Hi mrswann,
I stumbled across this post while trying to do the same thing. Your problem actually starts at line 1 of your IF activity script. The variable you are returning your result object to is 'activity'. I'm not quite sure if that's some sort of global variable but the article you cited is actually placing that value in the workflow.scratchpad global variable. Then they are using workflow.scratchpad again to retrieve that value in the IF condition evaluation. Your script should look something like this.
workflow.scratchpad.result = evalAccess();
function evalAccess(){
var result = { itil:false, facilities:false, cmms:false, none:false };
var vp = current.variable_pool;
if(vp.snow_itil == 'true')
result.itil = true;
if(vp.snow_facilities == 'true')
result.facilities = true;
if(vp.snow_cmms == 'true')
result.cmms = true;
if(vp.snow_cmms != 'true' && vp.snow_itil != 'true' && vp.snow_facilities != 'true')
result.none = true;
return result;
}
Then, in the condition field, it should look like this:
Does that make sense?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-19-2016 01:16 AM
Yes but I am not using the scratchpad to pass variables in, I understood that is just for proof of concept to show the workflow in action without having to go outside of the workflow to demonstrate... My previous role I am certain I was not using the scratchpad..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-19-2016 06:56 AM
That's odd. I'm not sure why the lab instructions would tell you the wrong way to do something. It worked for my use case and I wouldn't see any problem unless you had two IF activities running in parallel (for which you could just rename the result object).