Cancel Flow when Record State changes prior to Orlando

[jxsaxton421]

My use case is pretty much what this user ran into, being able to cancel a flow when a record state changes. https://community.servicenow.com/community?id=community_article&sys_id=ef133788db3af780190dfb2439961...

However, the kind and helpful folks in the SNDevs slack told me it would not be appropriate to gliderecord the sys_flow_context table and update that system table directly. 

One of the users commented to use this API. However, this is undocumented and I attempted to use it in a business rule to cancel my single flow but ran into a cross scope error. In my business rule it also generated 300 times on update for one record that I changed (not sure what else was going on). 

//use the flow contect record id
var gpa = new sn_ph.GlideProcessAutomation(current.flow_context);
gpa.cancel("description of why it has been cancelled");

The folks on Servicenow Slack said to use the API for Flow Designer: There is a method .cancel in the api that does work in my PDI which is in Orlando, but my company instance is on New York and we won't be on Orlando for a little while. 

https://developer.servicenow.com/dev.do#!/reference/api/orlando/server/sn_fd-namespace/ScriptableFlo...

This would be the best way to handle it probably since it sounds like the api handles all the internal stuff that messing with the context record does not. (Namely, the background events that get passed around). 

Anyone else been able to solve this issue in New York? 

[Chris Raga]

A couple of things to note:

• current.flow_context will only work on flows running on the Requested Item [sc_req_item] table (the field flow_context only exists on that table), so there could be a chance you just cancelled all flows in the system. 
• the 'sn_ph.GlideProcessAutomation' script is actually found on the UI Action 'Cancel' on Flow engine context [sys_flow_context] table (/sys_ui_action.do?sys_id=eddf8dc053113200f5bf435723dc3459)
• If you are looking to cancel one specific flow, you can run this script:

  //query the context table for your flow executing on your record
  var flow = new GlideRecord("sys_flow_context");
  flow.addQuery('name', 'My Flow Name');
  flow.addQuery('source_record', current.getUniqueValue());
  flow.query();
  
  if (flow.next()) {
  
      //get your flow's context
      var gpa = new sn_ph.GlideProcessAutomation(flow.getValue('sys_id'));
  
      //if the flow isn't terminated (see UI Action condition)
      if (!gpa.isTerminated()) {
  
          //cancel the flow and provide the reason
          gpa.cancel('Cancelling this flow due to process XYZ');
      }
  }​

• This script only works for flows that are executing on a record (So scheduled flows won't work)
• If you are running this from a scope, the first time bombs while all the cross-scope permissions are added, but subsequent calls work.
• If you run this from a background script, you'll notice you are affecting the sys_json_chunk table but you also affect the sys_rw_action table which appears to be listeners and the context itself if actually updated.
  

Hopefully this helps! Your post got me started, so I appreciate the time you took researching this!