Blocker in utilization of workflow.scratchpad in workflow for certain functionality

[Arjit Gourav]

Hi Team. We have a hypothetical scenario of workflow not proceeding further due to a function inside Script which is associated to workflow. Inside the function, workflow.scratchpad is used to store the asset/record details.

In a scenario, the tasks inside the Requested Item should proceed once the state of particular class of assets changes which is taken care via events.

E.g.- If we have two asset records and we release one asset from requested item / from parent , we are left with only one . After the only left asset state changes, the expectation is for the workflow to proceed as from the log we have checked, the workflow scratchpad re-captures the child records which contains only one Unique ID i.e. of the present asset.

But due to some reason, it doesn't go further and is stuck in the same activity where the condition is written to move the workflow further after state changes.

Note:- After re-triggering the same event for the asset record or if we have requirement to send event for 2 assets & are sending the event, flow proceeds which is confusing how in the first iteration it doesn't work.

[Michael Jones -]

Are you using a wait for condition, where you condition is based off an update to a record that is not the current record? The wait for condition will only check when the current record is updated. 

Usually for something like this you need to have a BR run on the table where the update you are waiting for is occuring, and then "nudge" the workflow usually something like this: 

var reqItem = new GlideRecord(sc_req_item);
       reqItem.get(current.sc_req_item);
            new Workflow().broadcastEventToCurrentsContexts(reqItem. 'update', null);
        

But that only works easily if you have a reference to the sc_req_item on the record that is being updated, or at least some way to find the specific sc_req_item you want to "nudge". 

In your case you might need to use a loop with an if check and timer instead of a wait for condition - with the general idea being that you go to the if and check if you condition is true, if yes, move on - if no, go to a timer with a duration (say 5 mins) and then connect back to your if. You keep going in a loop until the if is true, etc. 

[Arjit Gourav]

On the point adding a timer with certain duration, I actually have tried in the workflow on implementing the solution.

Did add a timer after the event activity and before the if condition, but didn't work in that way as well.