Await Expiry node fails to progress if a Basic User is raising a call

[AKJ]

We've just made live several new processes as part of a new directorate landing page, but we had to pull one process at the last minute as we think a bug in Hornbill is preventing it from progressing correctly.

This was not caught initially as we had extensively tested the processes with our Hornbill User accounts and it was completely fine, but when we tested it with a Basic User test account it didn't work properly.

After several hours of debugging, we narrowed it down to the Hornbill Automation node Requests > Suspend > Await Expiry. We had set different Expire Periods of 1 hour, 5 minutes and 1 minute (we're aware the latter doesn't always play ball but seemed OK once we 'nudged' it) but it never expires and moves on. We are obviously testing this in working hours and with respect to the Working Time Calendar.

The conditions required for this bug to manifest itself are as follows:

• It only occurs if a Basic User is raising the call, regardless of whether the customer is automatically changed to another user with a User licence later on
• A human never interacts with the call after it is created, AND before the first Await Expiry node is reached. This doesn't include opening and viewing the call

Upon reaching the instance an action is taken on the call, such as posting to the timeline (analyst or customer) or assigning it to an owner, it kicks the Await Expiry node into gear and after the stipulated time it continues as normal.

The types of request it is failing with includes service requests and change requests.

It really doesn't make sense why this node only works as intended for Hornbill Users, so I would really appreciate if someone can confirm if this is indeed a bug or if there's some whacky reason behind it.

[Steve Giller]

Can I first ask what you're using this node for?

If you need a Workflow to suspend for some reason there's almost always a better way than the Await Expiry node.

[AKJ]

On 30/09/2024 at 10:20, Steve Giller said:

Can I first ask what you're using this node for?

If you need a Workflow to suspend for some reason there's almost always a better way than the Await Expiry node.

We are sending a couple of external email authorisation nodes with an expiry time of 14 days, with a reminder email to be sent 7 days after raising the call. Sending the reminder email should only occur if there is no reply to the authorisation nodes, which we're happy works well. These occur via parallel processing.

It is the method we are using to count to 7 days to send the reminder email that is proving to be the problem. We've since tried 'Wait for Custom Field' for 7 days which should trigger once both emails are replied to instead of await expiry, but this too didn't work until we posted to the call's timeline or assigned it to someone.

If the reminder section of this parallel process can't move on, the process will be effectively stuck until someone interacts with it. We are implementing a temporary workaround of requiring our Service Desk to assign the call to someone, in order to kick the first suspend node into gear and at least have the process working.

We are curious as to what other nodes and solutions we could employ for this, as it sounds very much like we should avoid using the automation node Service Manager > Entity > Requests > Suspend as much as possible!

[Steve Giller]

I'd suggest setting the initial authorisation email to expire after 7 days.

At this point your Decision node can branch to a second Authorisation node if the outcome is Expired, otherwise progress and react to the provided response.

This removes any requirement to suspend or otherwise pause the Workflow as the 7 day reminder is managed by the Authorisation itself.

[AKJ]

21 hours ago, Steve Giller said:

I'd suggest setting the initial authorisation email to expire after 7 days.

At this point your Decision node can branch to a second Authorisation node if the outcome is Expired, otherwise progress and react to the provided response.

This removes any requirement to suspend or otherwise pause the Workflow as the 7 day reminder is managed by the Authorisation itself.

Thanks, I think this is what we had done previously so interesting to see this is the preferred method of sending a reminder, at least for the time being.

[Steve Giller]

Another option is to place the Request on hold (have the Place On Hold node immediately before the Authorisation node) - as you're awaiting an Authorisation that would be normal practice - and then take it off hold once the Authorisation has been processed.

[Berto2002]

We use Ext Auth A LOT for Requests logged by our Basic users and expiry after 3 days is a core feature. We are looking to see if we are affected by any issue here.

@AKJ On separate subject where you said, "We've since tried 'Wait for Custom Field' for 7 days which should trigger once both emails are replied to instead of await expiry", we were testing the "Suspend Wait For Custom Field" node and noted it did not react to an API updating h_custom_d. I reported it as a potential defect to HB Support. Hornbill have acknowledged that the feature is missing a trigger which they have added to their stack for improvement; but if you have Premier Support and need it fixed you could raise an Incident because they may think it's API-specific.