Expiry time issues. My wait for "5 days" took "12 days" (18 elapsed)

[Berto2002]

I believe I have worked-out how the expiry works and I don't like it! I wonder if other users have the same experience and feel the same.

I have a 5-day wait/expiry node:

And yet, in the log, that gap was 18 elapsed days (12 working days):

After the 5 days it moves a card on the board. I have a further node that waits 15 days before removing the card from the board; and that has now passed 15 elapsed days.

In this Wiki article (Hornbill How To: Two Stage Closure in Service Manager - Hornbill), there is a statement "The expiry period is in working hours and will adhere to the hours configured in the "ServiceDeskDefaultCalendar"".

We have this calendar which uses 10 hours per day 5 days per week:

My theory is that the waiting time of a DAY, as configured in the expiry, counts as 24 HOURS but that the system only counts towards that at the rate during the hours configured for service in the calendar; in my case, 10 hours of that per working day.

This ties-in with what we have seen:

Configured: 5 (days in expiry setting) x 24 (hours) = 120 hours

Experienced: 12 (working days) x 10 (hours) = 120 hours

This is not at all intuitive and it means the administrator needs to undertake a calculation to set this each time.

1) is there not a better way to do this?

2) please could you update the Wiki to draw this out; perhaps an example calculation like the above? It would have saved me hours of investigation trying to understand it!

[Guest Mary]

@Berto2002

Please see the https://wiki.hornbill.com/index.php?title=Corporate_Service_Level_Agreements which makes reference to an FAQ with full details relating to expiry time configuration on business process nodes https://community.hornbill.com/topic/13775-setup-and-configure-timers-in-service-manager/

 

 

[Berto2002]

@Mary. The linked article is useful. Can youput it in the Wiki? However, that article (linked here) states "IMPORTANT: the above does not apply when configuring expiry times on human tasks. Human tasks do not account for Working Time Calendar and as such the above setup does not apply in this scenario". But I have just proven it DOES apply to Expiry Tasks... It very much does need the same calculation, right?

 

[Victor]

On 9/15/2021 at 3:36 PM, Berto2002 said:

But I have just proven it DOES apply to Expiry Tasks... It very much does need the same calculation, right?

Yes, assuming the "expiry task" you mention is a (or part of a) Service Manager workflow node. The statement that "Human tasks do not account for Working Time Calendar and as such the above setup does not apply" is valid. Perhaps there is a misunderstanding in what you mean/understand by "expiry task" and what we (HB) define as "human task".

[Martyn Houghton]

@Victor

We raised this back in 2019, where as per @Berto2002 experience, the suspend await expiry node is applying the default working time calendar to any duration set in the node. This is one reason we not able to use the node in our BPM that require a slight delay in the workflow between calling integration or get information nodes to ensure they work or the relate cache has been updated.

Cheers

Martyn

 

[Victor]

19 minutes ago, Martyn Houghton said:

This is one reason we not able to use the node in our BPM that require a slight delay in the workflow between calling integration or get information nodes to ensure they work or the relate cache has been updated.

@Martyn Houghton there should be no need for any "slight delays" in a workflow... if you find there is a need for that please do let us know so we can look into this...

Note: I understand there were some timing issues related to workflow asynchronous node execution in the past but these either have been addressed and/or if there are still issues of this nature they need to be addressed, as such we need to be made aware of such issues...

[Martyn Houghton]

@Victor

We were told at the time to put additional steps in the workflow after a suspend node (Place on Hold) before running the Get Requests Details node to check the status of the request to determine if its is now 'off-hold' or has been updated by the customer. I will remove these, test and log a separate post if the issue is occurring again.

In terms of the scope of this post, the Suspend Await Expiry is applying the default working time calendar to the duration. Therefore there needs an enhancement to allow you to enable or disable WTC.

Cheers

Martyn

[Berto2002]

On 9/28/2021 at 12:53 PM, Victor said:

@Martyn Houghton there should be no need for any "slight delays" in a workflow... if you find there is a need for that please do let us know so we can look into this...

@Victor I have just come across a need for a short-delay. 

 

[Victor]

@Berto2002 - I'll reply on the thread you linked