email update notification issue when a ticket is on hold

[Gary@ADL]

Hi Guys - we've just started to use sub-statuses within our organisation, although on starting to use it ive noticed an issue maybe , i can see why its happening, but i was wandering if theirs a way round it.

 

so currently, when you have a ticket (not on hold) and its updated, we receive a server-side system generated email to advise us the ticket has been updated, by email and also what the text in that email says - which is great and very useful as you can see the update in your email without having to browse through to the ticket.

 

however ive noticed that when i set the call to on hold with a sub-status, and the customer emails about the ticket, i still get the email notification, but instead of telling me what the customers update was, it just tells me that  the sub-status has changed - Sub-status has changed from 'With Customer' to 'In Progress' following a customer update Request has been taken off hold - which isn't nearly as useful

 

i kinda get why its doing it - because the job has been updated by customer, this generated an email, but at the same time the ticket is also knocked off hold due to customer update, so in the seconds it takes the email is to generate, the last update isn't the customers update anymore,. its actually the update advising the status being changed,

is there anyway this can be amended so the emails still show us the customer update that triggered the email notification when the call was on hold?

 

thanks

[David Hall]

Hi @Gary@ADL

Thanks for the post,  could you confirm which routing rule operation you are using to apply the email updates? e.g. in my screenshot I'm using "logOrUpdateIncident".  

In the latest version of Service Manager (2.49) we made a change to fix the scenario you have raised, however I've just taken a look at the various available operations and I'm guessing that you may be using the "updateRequest" operation which for some reason did not have the same update applied as the other "logOrUpdate" operations.

I will make the same change to the "updateRequest" operation which will solve the issue in future, however it may not make it into the next update (2.50) in which case it will be available the following update (2.51)  

In the short term, if suitable and should you wish to, you could try using the "logOrUpdate" operation which will send the notification with the  original email update content before the status update is applied. 

Any queries just ask.

Kind Regards,

Dave.

[Gary@ADL]

thanks @David Hall you were correct, we had it set tu update request, ive now changed this to logorupdateincident,

 

so hopefully this sorts it

 

 

[Gary@ADL]

Hi @David Hall - we have had to change this setting back to 'updaterequest' as we noticed a few strange things happening,

 

emails that were sent to the helpdesk with the call reference in the subject were no longer being auto-applied to the calls (only noticed it when the sender is the not the same as customer, unsure if this is the same when the customer emails about there own ticket),

 

also we have noticed some emails from external users are now being auto-logged as tickets - when previously we didnt and dont have this configured,

 

we'l leave our setting as update request, but if you could get the changes applied to it as mentioned in your previous post that would be great

 

thanks 

 

 

[David Hall]

Hi @Gary@ADL

Its most likely just some additional settings that would need to be altered to get the other flowcode working as you would like, but in any case I have the fix in with the updateRequest flowcode for the 2.51 release so that should be available to you soon.

Regards,

Dave.