- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-04-2022 04:41 AM
Hello SN developers,
We have a flow which is triggered by a script to wait for a end user answer.
If the same flow is triggered again for a RITM than it checks first: 'Is another flow already running?'.
If a flow can be found, than the first one will be cancelled and the second one will now wait for the end user feedback.
With the SN version 'Quebec' this works all fine.
The source record for the flow was always the RITM and so we were able to find already running flows and cancel them.
Now we habe the SN version 'San Diego' and the behavior has changed.
The source record for the triggered flow is e.g. the save-button-object. Or a client script. But not longer the RITM record.
The second flow is not able to find the other one and so both flows are running and they can affect each other.
For Incidents we can use the flow directly and do not need a trigger from script. The flow checks if an incident record fits the condition and then starts correctly. The source record is the INC record.
But for Requested Items there was no possibility to use the flow without a script trigger.
How can we deal with this issue?
Does anybody had such a request and was able to fix it?
At the moment I am thinking about reworking the flow to react directly on a task record update without the trigger from script. But that is quite complicate because some of the conditions are only available on the RITM record.
Thanks in advance!
Best wishes
Michaela
Solved! Go to Solution.
- Labels:
-
Scripting and Coding
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-15-2022 01:37 AM
I asked the SN support team and got this answer.
We have to manipulate the source record manually (in the calling script):
try {
var inputs = {};
inputs['table_name'] = 'sc_req_item';
inputs['request_item'] = current;
var result = sn_fd.FlowAPI.getRunner().flow('global.snow_test_flow').inBackground().withInputs(inputs).run(); //run the flow
} catch (ex) {
var message = ex.getMessage();
gs.error(message);
}
var contextId = result.getContextId(); //get flow context sys_id
var fc = new GlideRecord('sys_flow_context'); //query the table sys_flow_context using the flow context sys_id to get the sys_flow_context record and populate the fields source_table and source_record
fc.addQuery('sys_id', contextId);
fc.query();
while (fc.next()) {
fc.setValue('source_table', 'sc_req_item');
fc.setValue('source_record', current.sys_id); //sys_id of the RITM on which you want to start the flow
fc.update();
}
I tried it out and it worked fine for our issue.
Instead of
var result = sn_fd.FlowAPI.getRunner().flow('global.snow_test_flow').inBackground().withInputs(inputs).run(); //run the flow
I used this flow call function
var flowContextId = sn_fd.FlowAPI.startFlow('global.snow_test_flow', inputs);
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a month ago
Oh, it is a long time ago since I did that.
I think it was because we had already gained experience with that flow call and we knew how it worked.