I try to implement a custom app, which does something similar to the
Required fields validator app, which makes some fields mandatory in a dynamic way by using the event.helper.fail in interceptable events (scroll up one page from Common Event).
The main difference is, that it shows a confirmation message before intercepting.
Says “Ticket is not categorized completely - Proceed anyways?” No/Yes
Means, the user/agent is asked if the ticket should be saved without mandatory fields set and interception only made when user clicks “No”.
This is because we know, that some tickets cannot be categorized, but some are not categorized because agents forget. With our app, we want to remind agents to think of categorizing.
The confirmation message should only pop up on ticket status Closed and Resolved.
Now here’s the issue.
In order to catch every action, where a user can set a ticket to Closed or Resolved, you need to intercept
Send and set as Closed/Resolved event → Not working
I do not get the information if the user has clicked on “Send” or “Send and set as …” within the event itself. So no chance there.
What I do get is that the “Properties Update” (the first one in this list) event is triggered, so I thought that may capture “Send and set as …” aswell. But it seems that the product is doing a non-interceptable update before it does another update which allows interception. Because I get a “Properties updated” message immediately followed by my interception:
So the interception would work but doesn’t have any effect, because the ticket was already updated milliseconds before.
Has anyone tried something similar? Is this a bug? Or just my usecase so niche that the product team did not consider making the “Send and set as …” interceptable?
@Freddy - Do you have any idea how to determine, if the “ticket.sendReply” interceptable event is triggered from a normal “Send” action or a “Send and set as” action?
As per your question, to determine if the “ticket.sendReply” interceptable event is triggered from a normal “Send” action or a “Send and set as” action, I suggest you follow these steps:
Intercept the ‘ticket.sendReply’ event by attaching ‘before’ handler to the event.
In your eventHandler function, you can intercept the event and fetch status changes of the ticket. However, the ‘ticket.sendReply’ event does not contain the information on whether it’s triggered from a normal “Send” action or a “Send and set as” action directly.
One way to identify the action is to listen to ‘ticket.propertiesUpdated’ event, which will be triggered when the ticket has status changes. You can use this event to monitor ticket status, and then, once the ‘ticket.sendReply’ event is fired, analyze the ‘ticket.propertiesUpdated’ event to correlate the flow.
However, this method might not be fail-proof, as it requires careful synchronization of events and correlation, which might not always be in the perfect order.
I understand it’s not an optimal solution, but currently, there is no direct way to identify whether the ‘ticket.sendReply’ event occurred from a normal “Send” action or a “Send and set as” action. I hope this helps for your current use
In theory, what you described is possible and I already implemented a solution,
which uses the ticket.propertiesUpdated (which is intercept event aswell) to intercept the update (which is exactly what I need).
Here’s the issue:
The Freshdesk standard behaviour when using “Send and set as …” is to NOT wait on interception.
So is this a bug of the standard behaviour?
I understand that you are facing an issue with the Freshdesk standard behavior of the “Send and set as …” action, where it is not waiting for the interception. It is possible that the Freshdesk standard behavior is designed this way in order to ensure uninterrupted usage despite the presence of an intercept condition in the custom app.
While I cannot confirm if it’s a bug or an intentional design choice, I understand that it’s causing problems in your use-case. As a workaround, you may continue using the ticket.propertiesUpdated intercept event to achieve your requirement, even though it may not be the ideal solution.
