How are you handling the re-opening of tickets when a forwarded requester replies?

Hi Zack.

On our side, for closed tickets, we simply let sender know that they are replying to a closed ticket and that they need to re-open a new ticket.

But, we have customized the re-open workflow, so, not only forwarded but also CC’ed people that respond re-opens the ticket (and have set the Condition to Anyone).

In our case, we simply check the domain of the person responding to a ticket; if it is our domain, we skip such response, as it is considered and Agent update; for the remaining condition, it indeed reopen the ticket.

We’re now pushing to prod an update to such workflow for the event in which an Agent is also the requester, performing such additional comparison, but the rest remains basically the same.

Hope this helps.

Cheers!

Elvis.

I ran in to a problem where tickets didn’t reopen when the ticket requester is an agent. I solved this by running an expression that checks the latest comment and compares the user id between requester and who mad the latest comment. If it is a match the ticket reopens. This way I don’t have to rely on who can perform the event.

But I have not checked if this is possible with forwarded requesters. Hopefully it can help anyway.

I haven’t run into any issues yet with this.  I have a simple workflow in place:

As @StaEri say and you could singel out if it’s a agent by API requester view for the ID, if it fails you know it’s an agent. 

You can also in the API check if it’s incoming, private/public and source. 

Service Desk API for Developers | Freshservice

Hi guys and @zachary.king !

I’ve done the following for a few of our customers, give or take based on specific requirements of course: 

This workflow assumes that re-opening of closed tickets is not allowed, which is a somewhat popular approach in the Nordics, and creates a new ticket with the last public note as a new private note in the new ticket. Please also note that this version allows for different methods, IT has the requirement of follow-up tickets while non-IT groups (for now at least) does not.

If the ticket is not closed, i.e pending, resolved or otherwise the workflow will set the status to open and notifies the assigned agent if present.

For now, this workflow only triggers on notes and replies added by the requester, my event is broad enough to capture forwards sent to the ticket as they are added as private notes but it’s content is not carried in the placeholder for [last public note] since it’s not public.

I’m considering duplicating this workflow but setting Agent instead of Requester in order to capture their replies as well.

This is the current version of the POST to create a new ticket, next level is to add it as a child ticket instead.

After a successful POST to create a ticket the workflow then captures the returned ticket ID and reuses it in a POST to create the new note. Yesterday I tried adding {{comment.body}} but it returned empty, a bug perhaps?

A note is also added as a confirmation in the original ticket:

And this would be the new ticket (3823 as mentioned in the note, next level could be to have an URL included to the new ticket for easier access for the agents) with the original description retained and the last public noted added:

Stay safe!

/Alex

JTAVOLARO wrote:

I haven’t run into any issues yet with this.  I have a simple workflow in place:

 

Thank you! we have something similar in place too, but it doesn’t get triggered when a response is added to a ticket from a “Forwarded User”. In your trigger, do you have it set to only “Requester” can perform this event? And can you verify that if you forward a ticket to a different requester, when they reply it reopens the ticket?

Thank you everyone for your input. I can see the use of expression nodes and the freshservice API as a way to identify who is interacting with a ticket. Perhaps with that information I can work to make sure tickets are re-opening whenever anyone interacts with them that isn’t the assigned agent!

zachary.king wrote:

JTAVOLARO wrote:

I haven’t run into any issues yet with this.  I have a simple workflow in place:

 

Thank you! we have something similar in place too, but it doesn’t get triggered when a response is added to a ticket from a “Forwarded User”. In your trigger, do you have it set to only “Requester” can perform this event? And can you verify that if you forward a ticket to a different requester, when they reply it reopens the ticket?

I generally don’t have that particular scenario, but I can test it out...

Hi, 

Did this tests, 

I have this 3 WFA, all they do is t o add a note. The event is set as the name applies 

Test one:

Ticket created on requester 
Forward to agent ( my self ) 
Replied from my outlook 
Agent only and Anyone ran 

Test two:
Ticket created on requester ( same ticket)
Forward to another requester not in the system ( gmail )
Replied from gmail 
Requester only and Anyone ran 

Next step would be setup the WR with API and use the ADD Child ticket endpoint. 
 

Event based on Public / Private will add another layer as Forward is set as Private even with requester. 

@zachary.king Did you manage to do this? I would also like to reopen, and change the priority of tickets to make them more visible for agents, if a reply is recieved from a forwarded requester. Best would be from anyone but agents. 

@StaEri How did you do that?

Hi.

The suggestion I made is the one we use.

It works for all cases:

If requester is external and replies, it reopens.

If CC replies, it reopens.

For Forwarded requester, if they reply,  it reopens.

If one Agent is the requester, it reopens.

For all other agents, it won't reopen.

Regards,

We utilize this trigger:

And this conditional:

This captures any interactions with a ticket that are not done by the assigned agent. Works for our use case. Hope that helps!

Zach, 

I just implimented that same thing in my helpdesk with replies, but not notes. thank you for showing your work like that. I ahve never used the Expression Builder before. 

@zachary.king  Ah very simple but works like a charm. I used the {{event_performer_email}}.

It was for me also the first time I use the Expresion Builer in a workflow. Thanks :-)

@Tony Gambino and @DirkH you both are very welcome! Glad I could help 😎