How to get the Flow sys_id (sys_flow_context.sys_id) from the trigger record sys_id?

Erik Gunther2
Kilo Guru

‎07-29-2019 01:37 PM

In a background script editor, I successfully ran the following methods to cancel a Flow Designer workflow:

var gpa = new sn_ph.GlideProcessAutomation('91dd1c84dbc73b849aab755a8c961993');
gpa.cancel('manually cancelled');

My issue is that this method requires the sys_id of the sys_flow_context record. If I'm on the record that triggers the flow, how do I get from the trigger record to the sys_flow_context sys_id?

When I look at how sc_req_item is implemented (trying to ascertain how this was done elsewhere), it has a Flow Context field. Do I need to do the same thing - add this field? If so, then from Flow Designer, how do I retrieve the sys_flow_context sys_id of the executing workflow in order to update the trigger table Flow Context field? Also, the link between sys_flow_context and trigger record must be available somewhere for this to work in the first place so I would think creating the Flow Context field should be unnecessary.

Note: I also did a search for GlideProcessAutomation in docs.servicenow and didn't find anything.

In addition, when I check the sys_flow_context table, there are 2 fields: Source Table and Source Record, which appear to be the right fields, but unfortunately, they are empty for my existing workflows.

Labels:
  • 10,989 Views
11 REPLIES 11

Erik Gunther2
Kilo Guru
In response to Aishwarya Prabu

‎05-03-2021 05:59 PM

I think unlike the other tables, the sc_req_item table has reference fields for this. See the screenshot:

 

find_real_file.png

Preview file
270 KB
0 Helpfuls

Ryan_Gray
Tera Contributor

‎11-02-2022 12:30 PM - edited ‎11-02-2022 12:31 PM

You should be able to query the sys_flow_context table passing the RITM's sys_id as the source_record.  Once you have the context record you can pass the sys_id to GlideProcessAutomation.

 

var contextRecord = new GlideRecord('sys_flow_context');
contextRecord.addQuery('source_record', <RITM sys_id>);
contextRecord.query();

 if(contextRecord.next()){
    var gpa = new sn_ph.GlideProcessAutomation(contextRecord.getValue('sys_id'));
    gpa.cancel(reason);
}

 

Another option that has worked for me is Using the documented FlowAPI cancel() method. It takes a context record and a reason.

 

var contextRecord = new GlideRecord('sys_flow_context');
contextRecord.addQuery('source_record', <RITM sys_id>);
contextRecord.query();

 if(contextRecord.next()){
    sn_fd.FLowAPI.cancel(contextRecord.getValue('sys_id'), reason);
}

 In both cases it appears that the cancel methods only cancel the called out flow. Any subflow will need to be queried and then canceled as well. The source_record for any subflow is the context record sys_id of the flow that triggered the subflow.

0 Helpfuls