Jump to content

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


Berto2002

Recommended Posts

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:

image.png.91b41ff79be7b0943b67144423b9f537.png

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

image.thumb.png.1733f4be0ee325c19fda4c4b8ac7492b.png

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:

image.thumb.png.6f798ff008e56edcae7a73a7480efe07.png

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!

  • Like 1
Link to comment
Share on other sites

@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?

 

Link to comment
Share on other sites

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".

Link to comment
Share on other sites

  • 2 weeks later...

@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

 

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...