Tickets assigned to Awaiting Authorisation team not automatically closing if it has not been authorised

[Archana]

There are requests assigned to the 'Awaiting Authorisation' team that have not been authorised and have not automatically closed as per the business process. These requests appear to have been submitted and remain in a state of limbo. We observed this for the tickets after 19 July 2023. The request prior to 19 July that was never authorised and processed correctly to closure.

The first request after 19 July that hasn't been authorised and hasn't progressed past the initial stage of hold after the first email was sent to the authoriser.

 

If calls do receive an email response, the process does continue and the call is moved onto the correct team. This issue is only affecting calls that never receive authorisation.

[Steve Giller]

11 minutes ago, Archana said:

There are requests assigned to the 'Awaiting Authorisation' team that have not been authorised and have not automatically closed as per the business process.

These requests will, in fact, be proceeding as per the Business Process. The BP will be set to wait for an Authorisation, and that's exactly what it's doing.
Authorising the Request will progress the Workflow, however this may introduce other complications (such as "Why am I suddenly receiving emails about this project we finished 3 years ago?") so that may not be a practical step.

There are two additional steps you can take in the Workflow - firstly, setting an expiry on the Authorisation so the Workflow automatically moves on after a set time. You can then check for expiry and take a suitable action, e.g. resend the Authorisation, cancel the project, etc. How to do this will vary depending on what method you are using to Authorise.
Secondly you can lock down the Request Actions until the Authorisation arrives/expires - look for the Access Control section of the Service Manager Business Process Workflow page.

[Archana]

There is ticket similar to this case, which is raised on 17 July. This was never authorized but correctly processed to closure. However the same not happening with ticket raised on 27 July.
below screenshot attached.

[Archana]

@Steve Giller Please note that we haven't made any changes our Business Processes and it stopped working after 19 July.

Below attached screenshot for references.

This is the active business process flow we have.

[James Ainsworth]

Hi @Archana

Thanks for your post.  Your first post mentions authorisations, so my assumption was that you are using the authorisation node and this is where the issue is.  The screenshot above references On-hold which is different from authorisations and they will behave in different ways.  Can you post the settings on your authorisation node that has the expiry set in it?

[Archana]

Hi @James Ainsworth

Thank you for the reply. Actually we don't use the Authorisation Node. We use the setup for Hold and once the the Hold is expired it will proceed to next step that is send reminder for authorisation and in case of no response it will lead to auto closure .
In our case it remains in the stage of Awaiting Authorisation and haven't moved to further steps as per business process.

[James Ainsworth]

Hi @Archana

I think that there are some crossovers in terminology that are making it difficult for me to understand exactly what the issue is.

I believe we can put aside anything to do with authorisations.  

The automation called Place on Hold which I believe you have labeled in your workflow as Put Request On-Hold.  This automation has an option labeled On Hold Until which takes the request off hold after the set time.  I'd be interested to know if you have this set to ignore or if there is a value set.  

The next node that you have in your workflow is the Wait for Request off-hold and from your screenshot you have this set to expire after 16 hours.  If you are working on a 8 hour workday, this would equate to 2 working days or weekdays.  I'm assuming that you have On Hold Until set to Ignore in the Place On Hold automation and you are just waiting for someone to manually take it off hold.

Once it goes to the decision node after expiry, I can't see all of the paths that it can take.  Once the expiry has been reached, do you find that it always goes down the no match route on the decision node or does it appear to never get past the decision node? 

 

[Archana]

Hi @James Ainsworth
 

Please find the below screenshot for Put Request On-Hold  option.

On Hold Until has been set as Auto here.

Once the hold expired it will send a reminder email and in case of no response it will lead to closure.

 

[Archana]

Hi @James Ainsworth

Noticed that the ticket in mentioned in question has sent a reminder email after 16 working days.
Screenshot attached.
Any insight on this please?

[WFMKC]

@James Ainsworth Think I maybe need to add a bit of additional context here.

As you have seen, we use 'Suspend' to manage the time (in our case 2 working days) before the BPM progresses to the next stage if it doesn't receive an email update (any email update progresses the request).  The issue for us appears to be that the suspend is never expiring when no update is received, therefore the call remains permanently stuck at the 'Wait for off hold' stage when it should actually progress to the next stage, which is to send a further reminder email to an authoriser (specified by a custom field in the original capture) and again suspend for 16 hours.  After this if a response still isn't received, it should progress to a closed state as not authorised.  If at any stage an email is received updating the call, it will progress.

This has always worked fine since implementation over 3 years ago, until after 19 July when it seems to have stopped.  I believe this corresponds with 'Service Manager' update that seemed to cause various issues for several customers.  As Archana has stated, we haven't changed anything it just stopped working after this date.

I wonder, is it possibly linked to this?

 

[James Ainsworth]

Hi @WFMKC

On 8/18/2023 at 3:10 AM, WFMKC said:

I wonder, is it possibly linked to this?

Possibly, but the KE00167283 was raised almost a year ago, so if this has only started being an issue for you since the 19th of July, there's a chance that something else might be causing it.  This KE is also referring to the Suspend->Await Expiry and your question is on the Suspend->Wait for Request Off Hold.

 

[James Ainsworth]

I've been trying to replicate using this workflow and so far it is working for me.  Well, initially it wasn't working for me but that was because I was testing outside of the working time specified in the default Working Time Calendar.  I'll try to have another look, but it might be something that needs to be taken up by Hornbill support.  

 

 

[James Ainsworth]

It might be worth removing and re-adding this expression.

It looks very different from mine.

[Archana]

Hi @James Ainsworth

To update on the above issue:
Without changing the Flowcode expression, we noticed that some of the tickets sent reminder email for authorisation after 16 hours of first reminder as expected. This happened to the tickets created on Oct 21 and Oct 22.

We noticed the issue reoccurs for the tickets created on and after Oct 26. The reminder emails are not being send after 16 hours. 
No clue why the issue resolved for few days and then again reoccurring.
Can you confirm if there any updates happened during these period.

[James Ainsworth]

Hi @Archana

Do you mean September?  Your dates above refer to dates in October, but we are only at Oct 2nd. Or are these requests that were raised last year?

[James Ainsworth]

Hi @Archana

Could it simply be that the authorizer is not seeing or receiving the authorization notification email so they never perform the authorization?

In the Hornbill Platform Configuration, you can view the direct outbound email messages which include the authorization notifications.  On each message, there is a delivery status that is available. 

 

The status delivery info can be quite detailed and help show why an email authorization notification is not being delivered.

[Archana]

@James Ainsworth Sorry I mean to say Sep 2023.

[Archana]

I can't be sure if it is authorizer is not seeing or receiving the authorization notification email so they never perform the authorization. In our case the first email is always being sent for authorisation. The reminder email is set to sent after 16 hours and this 16 hours suspend is never expiring to send reminder email.
Also I couldn't find anything related to authorisation in Direct Outbound email messages.
 

[Archana]

To add to above, We have noticed one of our ticket send reminder email on Oct 4 and another on Oct 5 at 10:29:40. But one other ticket supposed to send reminder on Oct 5 11:23 did not send the reminder. Both uses same workflow process. The issue still occurs to tickets assigned to 'Awaiting Authorisation' team after 05/10/2023 10:29:40(time approximate).

Is there any way to find out what exactly happening with the tickets. We did a comparison for the one send reminder  and other did not. But nothing suspicious.