How to reference a task outcome in a later stage

[Gary@ADL]

hi guys, sorry another question, please can you advise how i can refernce a task outcome (ideally the outcome, but a field from the custom capture section would do) in a later stage? i can see how to do it in a decision following the task, but id like to also do this in a later stage? ive tried using a get request info, but i cant see the business process tasks to reference the outcomes of.

 

thanks

 

[James Ainsworth]

Hi Gary,

I believe that you need to use a custom expression to get the Capture Task fields. 

1. On that same decision path select Outcome is: Custom Expression
2. Click on the Edit Expression button
3. Under the Selected Test Setup section, as you seen in the screen grab, click on the variable picker button, left of where it says Last Node->Outcome
4. The variable picker will show an expandable option titled Tasks
5. Select the name of the task and expand
6. In this list you should see your custom Capture Task Fields.
7. Select the one that you use.

 Hope this help.  Let us know if you have any more questions about setting this up.

[James Ainsworth]

Sorry... this still may not answer your question about using these same values in a later stage.  I'm having a quick look, but I believe everything is kept within each stage.

[James Ainsworth]

My first thought is to take the outcome of the task and within the stage where this task takes place, save the outcome to a custom field.  In the later stage you can then do a Get Request Info to retrieve the custom field.  Let me know if you think this will work for you.

[Gerry]

I *think* (but I am not 100 sure) there is a way in a custom expression to reference a specific task outcome using the Node ID. I would need to get someone who knows how to do this for sure to confirm, but I am sure that in the execution context we keep task outcomes against their specific Node ID. Its just knowing how to reference the outcomes (or even knowing of that task has been invoked and completed yet, for example the flow might not have got there in the process yet, then you inadvertently try to reference it by its ID, and it will error, most likely in a way that we could not handle very well. This is why the node ID's are generally hidden.  So probably not officially supported, but I expect its possible.  Maybe we need to consider a way where we can do this in a more supportable manor. 

The background to why this has not already been done is, outcomes were originally intended to be flow navigation pointers, but it seems some people do use them as a fast way to collect some basic information. 

Gerry

 

 

[NeilWJ]

Hi @Gary@ADL,

Will double check to see if we record previous stage task states within the BPM state. If we do we can add a feature to the variable picker to allow selection of a task from previous stages. I will let you know.

Cheers

[Gary@ADL]

thanks all fort your help so far

[HGrigsby]

Hi 

Was there ever an answer to this question.  Would be really handy if you could use the answers from the task in a later stage.

thanks 

Helen 

[Gary@ADL]

hi @HGrigsby you can reference answers from questions within the task quite easily, i never got round to trying to reference the outcome of the task properly though, instead i just had my "success" path set a field we dont use ("logging category"), and just referenced this later down the line,

 

thanks 

 

 

[Gary@ADL]

On 12/10/2020 at 8:48 PM, James Ainsworth said:

Hi Gary,

I believe that you need to use a custom expression to get the Capture Task fields. 

1. On that same decision path select Outcome is: Custom Expression
2. Click on the Edit Expression button
3. Under the Selected Test Setup section, as you seen in the screen grab, click on the variable picker button, left of where it says Last Node->Outcome
4. The variable picker will show an expandable option titled Tasks
5. Select the name of the task and expand
6. In this list you should see your custom Capture Task Fields.
7. Select the one that you use.

 Hope this help.  Let us know if you have any more questions about setting this up.

Hi @James Ainsworth - sorry to bug you, im trying but cant seem to get it reference the last node outcome in my decision? please see screenshots, ive tried to reference it by  setting it "lastnode outcome = Stageexpired" just typed manually, but this didnt seem to do it although i didnt try the full " &global{flowcode["stageexpired"] " value tbh but i dont think it will be that? 

 

 

[Gary@ADL]

 

 

ok so  ithink i can use this reference? but im not sure what the value would be?  @James Ainsworth

 

thanks

[Gary@ADL]

ok so i got my decision working using the "is set" variable...

 

  but ive now got another problem, when it loops back round to the "suspend bpm and wait for incident owner" after the node initially expires, it isnt applying the 2 minute expiry time again, its instead just constantly looping round and has filled my mailbox with about 200 emails in 2 minutes, it doesnt stop if you cancel the ticket either you have to cancel the workflow lol 

 

any ideas? 

 

thanks 

[Victor]

2 hours ago, Gary@ADL said:

after the node initially expires, it isn't applying the 2 minute expiry time again

@Gary@ADL if "it isn't applying the expiry again" usually means the conditions for suspend are not met so the node will not process with suspending the workflow. Looking at the node name, I assume is a "Wait For Request Owner" node? If so, does the request have an owner?

Regarding the condition, Stage Expired is not the one we need to use for this scenario (afaik). What we would need is to have an outcome as "expired" (same way the "Wait For Status Change" has).

EDIT: checking the above, the Stage Expiry outcome is set (only) when the node expires. So can be used. But ideally I think we would still want this to work same way as "Wait For Status Change"  where is sets the outcome as "expired". The issue with "Stage Expiry is set" is that once is set it will remain set so obviously a (any) subsequence check for "Stage Expiry is set" will return true.

[Gary@ADL]

1 hour ago, Victor said:

@Gary@ADL if "it isn't applying the expiry again" usually means the conditions for suspend are not met so the node will not process with suspending the workflow. Looking at the node name, I assume is a "Wait For Request Owner" node? If so, does the request have an owner?

Regarding the condition, Stage Expired is not the one we need to use for this scenario (afaik). What we would need is to have an outcome as "expired" (same way the "Wait For Status" has).

hi @Victor yes it its a wait for owner node -  no the ticket didnt have an owner (although if i recall it still blasted me with tickets even after assigning it an owner, which makes sense i suppose if my custom expression is incorrect... its going round the loop, checking for an owner, finding one so proceeding, checking if the stage expired is true which it is, and so looping back round forever. 

 

 

i cant seem to find an "outcome expired" option? the stage expired option seems to workm but its just that the original  "suspend bpm and wait for user node" isnt resetting when the pocess loops back to it, i need it to start its expiry timer from scratch when the process loops back to it, rather than what it seems tio be doing which is resuming where it left off. 

 

thanks  

 

[Victor]

51 minutes ago, Gary@ADL said:

no the ticket didn't have an owner

Then the node should have suspended the workflow and only resume on expiry (or owner being assigned). But you are saying it went through it without either? (no suspend after first suspend).

53 minutes ago, Gary@ADL said:

i cant seem to find an "outcome expired" option?

There isn't any for this node... it's something inconsistent with other suspend nodes which have it (I asked dev to look into it).

54 minutes ago, Gary@ADL said:

the stage expired option seems to work but its just that the original  "suspend bpm and wait for user node" isn't resetting

Yes because the condition required for expired would be "Stage expired is set", which is what you did. The thing is that once this is set, it is not un-set afterwards. So the condition will always return true on subsequent checks.

[Gary@ADL]

2 hours ago, Victor said:

Then the node should have suspended the workflow and only resume on expiry (or owner being assigned). But you are saying it went through it without either? (no suspend after first suspend).

yes it kept going im pretty sure - as ive deleted the workflow it will no longer let me view the ticket to double check, and im not keen to replicate as its churned out about 300 emails in about 4 minutes - im pretty sure i assigned the ticket first, then cancelled it, then deleted the workflow - ticket number was - SR00180811 if you can see anything your end.

. i think it kept looping round because the node is set to un-suspend when either - the ticket is assigned, or the node expires (after 2 mins in my case), and if as you say below that that stage expiry is not becoming un-set after the process lands back on it, then it will arrive on it, find it already expired (rather than a fresh node waiting for assignment or expiry), and continue along the flow round my loop.

2 hours ago, Victor said:

There isn't any for this node... it's something inconsistent with other suspend nodes which have it (I asked dev to look into it).

 

2 hours ago, Victor said:

Yes because the condition required for expired would be "Stage expired is set", which is what you did. The thing is that once this is set, it is not un-set afterwards. So the condition will always return true on subsequent checks.

ok so is there something a node i can use to un-set the expiry for original node? or is am i doing something wrong? 

 

am i on the right lines of what im trying to do here or is there a better node or flow i could be using? ive just muddling along as i go lol - overall im trying to generate an email notification when tickets logged via a certain flow (which is assigned to a specific catalogue item) are left unassigned for a certain amount of time - in this case its leavers so time sensitive that they are actioned.

 

many thanks 

 

[James Ainsworth]

Hi Gary,

I believe that the issue around the missing ''outcome expired'' is being looked at by the development team. 

I've not been able to fully test this but it seems to be working for me.  In this workflow, instead of checking for the outcome on the Wait for Owner, I have it looking to see if the owner has been set using the Get Request Information->Request Owner and then checking one of the owner's details, in this case their last name.

The Custom Expression I used was...

I does loop around and it pauses for the set expiry period each time it hits the Wait for Owner.  It continues to do this until the owner is set.  

 

[Gary@ADL]

thanks @James Ainsworth i'l give this a go

[Guest Paul Alexander]

On 1/30/2021 at 1:05 AM, James Ainsworth said:

I believe that the issue around the missing ''outcome expired'' is being looked at by the development team. 

Hi.

Has this been looked at please? I'm trying to branch a process based on whether a suspend node has expired, but when I output the result of &[global["flowcoderefs"]["Suspend1"]["stageExpired"]] to an activity (to see what the result is) it comes out blank. 

Is this going to be fixed please?

 

thanks

[Guest Ehsan]

@Paul Alexander,

The 'stageExpired' variable is set if the Request owner condition was not met within the configured expiry period. For example, if the expiry period was set to 2 hours in the Hornbill Automation node and the Request's owner was not set by an analyst within those 2 hours, the process will continue and the 'stageExpired' variable will be set to true. If the 'stageExpired' variable is not set, it indicates that the stage did not expire which means that a Request owner must have been submitted within the configured expiry period. Could you explain share your example and elaborate on why you believe that there is a problem with the Hornbill Automation? From what I can see, it is working as designed.

Ehsan

[Guest Paul Alexander]

Hi @Ehsan

Sorry....Looks like I got my wires crossed there...I had the 'on hold' and 'suspend' nodes both waiting the exact same time, so when the 'on hold' node came off hold, the 'suspend' node HADN'T expired, so the 'stageExpired' value wasn't being set. 

thanks though....