Suspend Node help please

[Sam P]

Hi everyone, I'm trying to Suspend a ticket until a date captured in the PCF (which is mapped to h_custom_a) and until that date passes, the ticket status should be updated to On-Hold and the resolution target should be paused.  I need help with a couple of things please:

1. What would my decision expression say to check if the date logged (today) is before or after the PCF answer (i.e. suspend or not)? 
2. I have observed the Pause function behaving differently to a manually applied Pause when actioned in my BPM using the Pause Resolution Timer node, what I have missed / done wrong?
   • Why is the Pause button still active when the request is on hold?
   • Why does the Resolution button say the target is ongoing when its been paused in the BPM?
   • Could/should I be able to manually release the Pause?
   •  
3. I don't seem to be able to update the status to On-Hold using the Update Request Status node...is there another way to achieve this?
   

Thanks in advance for any help you can give.

Sam.

[Victor]

16 hours ago, Sam P said:

a date captured in the PCF (which is mapped to h_custom_a)

First, I would advise against storing date values in text fields. If there are date fields available (custom fields that is) I would say use them for this purpose. Date/Time fields are h_custom_21 - h_custom_25 (https://wiki.hornbill.com/index.php?title=Mapping_Fields_from_Customised_Forms)

16 hours ago, Sam P said:

What would my decision expression say to check if the date logged (today) is before or after the PCF answer (i.e. suspend or not)? 

I am not sure why you would want it do do it this way, I think is much more simple to just use a workflow node to directly put the request on hold until that date (see below). You would use "On Hold Until" input parameter as a variable to which you will select the custom field captured during PCF.

16 hours ago, Sam P said:

I have observed the Pause function behaving differently to a manually applied Pause when actioned in my BPM using the Pause Resolution Timer node, what I have missed / done wrong?

There are 2 different functionalities here, one is the request status, where "paused" means "on hold", and the request timer being paused. Mind you that the request and request timers are mostly independent entities that work as such (see more about this on the notes below). For example you can choose to have the timer paused but the request can be active, e.g. resolved (so nothing to do with on hold status). When you "manually" apply pause you are effectively putting the request on hold (change it status - see more about this on the notes below). When the "Pause Resolution" timer is used in the workflow that will only pause the timer, it will not have any effect on the request status.

Note: although the request and the timer(s) are independent entities this does not mean they don't interact. When a request is put on hold the timers are also paused automatically and then resumed when the request is taken off hold having new targets calculated based on the amount of time the request has been on hold.

16 hours ago, Sam P said:

Why is the Pause button still active when the request is on hold?

I would not look at this as the "Pause" button, but as the "Change Request status button from on hold/off hold". The "Pause" you see there displayed is just a label to indicate what the button will do when used at that specific time. If the "Pause" label is displayed the request is not actually on hold, perhaps you are incorrectly reading the timer paused as also meaning the request is on hold. I hope the above re: status and timers explains more about why.

17 hours ago, Sam P said:

Why does the Resolution button say the target is ongoing when its been paused in the BPM?

Because the timer is still there, is just temporarily paused. So even paused, the target is still effectively ongoing.

17 hours ago, Sam P said:

Could/should I be able to manually release the Pause?

Assuming you are referring to the timer pause then no, the resolution timer can only be paused and resumed by or via the BPE. 

[Sam P]

Hi @Victor , wow thanks for such a comprehensive reply. 

We are only 2 months live with Hornbill and therefore its really helpful to have your input. 

6 hours ago, Victor said:

First, I would advise against storing date values in text fields.

I remembered quite quickly that there were dedicated date custom fields so thank you for the clarification.

6 hours ago, Victor said:

I think is much more simple to just use a workflow node to directly put the request on hold until that date

Assuming this will pass straight through the node if the date is the past?  I will try it! 

6 hours ago, Victor said:

perhaps you are incorrectly reading the timer paused as also meaning the request is on hold. I hope the above re: status and timers explains more about why.

 Yes, I think I need to read and re-read this a few times but I think there is some crossover in my understanding, thank you for clarifying.

I will continue to look at this over the next few days.

Thanks for taking the time to respond.

Sam.

[Victor]

14 hours ago, Sam P said:

Assuming this will pass straight through the node if the date is the past?

Well... not quite unfortunately... Update On Hold node in the workflow does not allow to pause the request (put it on hold) for a past date... it will throw an error if so... as a side note, what would be the business scenario for you where the date captured in PCF is in the past?

Another aspect to consider if you go with the On Hold node is that you also would need a secondary node in the workflow to Suspend Wait For Off Hold. So you have 2 nodes, first will put the request on hold and the other will also suspend the workflow execution until the request comes off hold. This is because while the request and the respective workflow interact with each other in various forms, they are essentially independent entities and they can perform various functions independent of each other. If you need them to behave in sync at certain stages (e.g. this scenario) then both will have to be configured to behave the same at that specific time.

[Sam P]

50 minutes ago, Victor said:

Well... not quite unfortunately

Ah so this was the reason for me trying to work out if i needed a decision to say...is date in the future..yes/no.  Would I still need this? 

 

51 minutes ago, Victor said:

what would be the business scenario for you where the date captured in PCF is in the past?

Our leavers process is a bit hit and miss...we are often told of people who have left after the last working day, in this scenario I would want the Business Process to start straightaway.  If the request is made in advance of the last working day I would want the process to be stopped until that date.  There's a number of human tasks that are generated as part of the process and I'm essentially trying to stop them from being generated until work should start on them.

[Martyn Houghton]

@Sam P

We use the the Get Local Time node ahead of a decision node which then branches whether the date is in the future or the past. If its in the future we then proceed to put the request on hold, if not we just get on with it.

Cheers

Martyn

 

[Sam P]

@Victor @Martyn Houghton I wanted to extend my thanks for your help with this...along with this post here I have been able to get my process working perfectly for us. Thank you