Lifecycle Event trigger script problem when using sys_id in variable in query

karoly_gersi
Giga Expert

Hello all,

 

Not sure if this is only an Activity Set trigger script-related issue only but here is what I experienced. I had to use a scripted condition for an Activity Set trigger, it checks a date and the completion of the previous Activity Set. The date part works, but the rest does not. Here is my script:

 

(function shouldActivitySetTrigger(parentCase, hrTriggerUtil) {
    var prerequisiteActivitySetId = '12345678912345678912345678912345';
    var parentCaseID = parentCase.sys_id.toString();

    var grActivitySets = new GlideRecord('sn_hr_le_activity_set_context');
    var query = 'hr_case.sys_id='+parentCaseID+'^activity_set.sys_id='+prerequisiteActivitySetId;
    grActivitySets.addEncodedQuery(query);
    grActivitySets.query();
    if (grActivitySets.next()) {
        if (grActivitySets.state !== 'finished') {
            return false;
        }
    }
    return true;  
})(parentCase, hrTriggerUtil);
 
I decided to check the context manually because the OOTB function offered via the hrTriggerUtil instance kept returning false even if the Activity Set has finished. But this approach does not work either (it does not find the record, getRowCount() shows 0 ), and it seems that the reason is somewhere around the parentCaseID variable. 
 
If this sys_id is hard-coded in the query, it works, even if the activity_set.sys_id is a variable. The "parentCase.sys_id" is originally of object type, but converting it to a string did not help either (I tried different methods, none of them worked).
 
I'm using addEncodedQuery() because addQuery() did not work in the first place. If I log the query, I can see it correctly (the same query I get when I query the table with the same values in the backend).
 
Does anyone have any idea why is this happening? (Keeping parentCase.sys_id in a variable is inevitable in this case.)
 
I found out that 'current' is also available in the script context but setting parentCaseID to current.sys_id did not work either, however, the value was the same.
 
Thanks for any hint that may help me solve this.
1 ACCEPTED SOLUTION

karoly_gersi
Giga Expert

Hi @Sandeep Rajput and @tejas1111 ,

 

Thank you for your valuable contribution to the issue!

 

However, it turned out that the problem is rooted in the operation of the ServiceNow system, one level higher than I expected. There was no problem with the query, with the variable and the ACLs, what happens is that  the query runs before the context record is created. It may be considered a ServiceNow bug since I basically did what is OOTB functionality (if you remember, the OOTB script that SN recommends did not work either). I could log the parentCaseID and it returned a valid ID because the parent case is already created when the trigger script runs but the context record does not exist yet (I used before query and before insert Business rules to log data and the sequence shows that the query is run before context record is created).

 

A possible workaround is to create a new Activity Set before the problematic one (which is not shown to the user on the portal) in which there is only a flow type task and the query is done from the subflow that's attached to it (in a do...while loop), then the original Activity Set only needs to wait for its completion. I tested it, it works fine.

 

Hope this will reach lots of fellow developers who ran into this issue.

 

View solution in original post

9 REPLIES 9

Sandeep Rajput
Tera Patron
Tera Patron

@karoly_gersi The code seems okay to me and as you mentioned it works with a hard-coded sys_id so it should work with parentCase.sys_id as well. Did you try to log the value of parentCase.sys_id value using gs.info(parentCase.sys_id); doe it return a valid sys_id?

Hi @Sandeep Rajput ,

That's right, the log shows the valid sys_id all right. Its type is object though (that's why I tried to stringify it) but when I gs.info it, I can see the string value. 
Do you think it is a type issue at some point?

@karoly_gersi Did you check the records in sn_hr_le_activity_set_context and see if you have more than one records for the same activity and parent case id.?

I checked it, yes, there is only one record. I filtered the table with the sys_ids that I use in the script. But if the query worked, it would return all records, the problem is that it returns 0 rows.