I have built a custom severless app that sends a notification to a third party Chat application called Fuze. I am using the onTicketCreate, onTicketUpdate, and onConversationCreate events. Both the onTicketCreate and onConversationCreate events work by sending a single notification to the chat app. However, the onTicketUpdate event is duplicating itself and running twice, sending two notifications.
When I look at the serverless logs it shows the event being triggered twice regardless of what properties I change on the ticket. For example, I will change the source and click update on the ticket details page, and this will trigger the onTicketUpdate event twice according to the logs, and the fact that I get two notifications in the third party chat application.
I tried this in my Fservice and it seems that there is only one event triggered per property update. Can you also check if you make any property updates in onTicketUpdateHandler? That in turn might trigger another event. Try to provide the server.js file also. I will have a look
Hello @shravan.balasubraman, Below is the code that I am using. I don’t see where I would be triggering a second event. All we are doing is triggering a notification to be sent using a post request. Thank you for looking into this for me.
const axios = require('axios').default;
exports = {
events : [
{
event : 'onTicketCreate',
callback : 'onTicketCreateHandler'
},
{
event : 'onTicketUpdate',
callback : 'onTicketUpdateHandler'
},
{
event : 'onConversationCreate',
callback : 'onConversationCreateHandler'
}
],
// args is a JSON block containing the payload information.
// args['iparam'] will contain the installation parameter values.
onTicketCreateHandler : function (args) {
console.log('Ticket Created');
console.log(args);
if (args.data.ticket.custom_fields[0].value !== null) {
axios({
method : 'post',
url :
'https://api.fuze.com/chat/v2/webhooks/incoming/apiKey',
headers : {
'Content-Type' : 'text/plain'
},
transformRequest : [
(data) => {
let ticketSubject = JSON.stringify(args.data.ticket.subject);
let majorIncidentType = JSON.stringify(
args.data.ticket.custom_fields[0].value
);
let ticketID = JSON.stringify(args.data.ticket.id);
data =
`Ticket ${ticketSubject} has been identified as a ${majorIncidentType}. Please follow the link below to view the ticket.` +
'\n' +
'https://cedservicedesk-fs-sandbox.freshservice.com/helpdesk/tickets/' +
ticketID;
return data;
}
]
});
}
},
onTicketUpdateHandler : function (args) {
console.log('Ticket Updated');
console.log(args);
if (args.data.ticket.custom_fields[0].value !== null) {
axios({
method : 'post',
url :
'https://api.fuze.com/chat/v2/webhooks/incoming/apiKey',
headers : {
'Content-Type' : 'text/plain'
},
transformRequest : [
(data) => {
let ticketSubject = JSON.stringify(args.data.ticket.subject);
let ticketID = JSON.stringify(args.data.ticket.id);
let status = JSON.stringify(args.data.ticket.status_name);
data =
`Ticket ${ticketSubject} has had it's ticket properties updated. It's current status is ${status}. Please follow the link below to view the ticket.` +
'\n' +
'https://cedservicedesk-fs-sandbox.freshservice.com/helpdesk/tickets/' +
ticketID;
return data;
}
]
});
}
},
onConversationCreateHandler : function (args) {
console.log('Note or Reply Added');
console.log(args);
let ticketID = JSON.stringify(args.data.conversation.ticket_id);
let url = 'https://cedservicedesk-fs-sandbox.freshservice.com/api/v2/tickets/' + ticketID
let apikey = 'XXXXXXXXXXXXX';
axios({
method:'get',
url,
auth: {
username: `${apikey}`,
password: 'X'
}
})
.then((response) =>{
console.log(response.data.ticket.custom_fields.major_incident);
let isMajorIncident = response.data.ticket.custom_fields.major_incident;
if (isMajorIncident !== null) {
axios({
method : 'post',
url :
'https://api.fuze.com/chat/v2/webhooks/incoming/apiKey',
headers : {
'Content-Type' : 'text/plain'
},
transformRequest : [
(data) => {
let ticketSubject = JSON.stringify(response.data.ticket.subject);
let ticketID = JSON.stringify(response.data.ticket.id);
data =
`A new comment has been added to ticket ${ticketSubject}. Please follow the link below to view the ticket.` +
'\n' +
'https://cedservicedesk-fs-sandbox.freshservice.com/helpdesk/tickets/' +
ticketID;
return data;
}
]
});
}
}).catch(function (error) {
console.log(error);
});
}
};
Hello @Saif and @shravan.balasubraman, I have only been able to test this in our freshservice sandbox environment. I don’t want to install it into production until I know it is good to go.
In the sandbox environment I have had this anomaly happen when simply local testing, as well as after I package the app and install it through the developer portal into our sandbox.
Hope this clears things up. Thank you for looking into this for me.
Hi @Zach, Can you try to upload the custom app in the non sandbox account. Will that be a problem. If no, please ensure if the same happens there. Meanwhile let us look into why this happens in sandbox env.
Hello @shravan.balasubraman, due to the nature of this app we cannot install and test in the production environment without disruption and alerting of stakeholders. Perhaps this is just an issue with the sandbox environment. But its risky for me to push this to production without first ironing out the details in our sandbox.
I have created another application that requires creating a Fuze notification similar to the above scenario. I went ahead and built it and installed the application in the Production Environment, thinking maybe it is just a bug in the sandbox environment but I am still having weird behavior even from production.
I will try to explain…The application utilizes onTicketCreate, onTicketUpdate, and onConversationCreate.
I created a ticket, and from the new ticket page, I filled out my fields and made sure to include the required group that would trigger my if statement to then send the notification to fuze.
This caused 2 notifications, 1 for ticket creation, and 1 for ticket updated and they appeared in the incorrect order with the update notification appearing first
Then I simply updated the status of the ticket to “Pending”, this triggered 2 more notifications but this time they were duplicates of eachother, as if the onTicketUpdate was sent twice.
Thanks for taking up the effort and explaining it @Zach.
Let me first check if there is some discrepancies from the app platform’s end. Is it possible for you to recall the range of date and times when you saw this behaviour happen?
Is it only those dates and timings when this incident occurred, or does it happen every-time when those product events are triggered?
This is a recurring problem in both the sandbox and the production environment. I have been testing this application throughout the build process all last week. The issue presented itself originally, at the same time this original post was created. So back on May 22nd. I stopped working on the original application because I was not able to test in the production envrionment as one of the steps in troubleshooting that you mentioned in the above thread. This time I took the risk and installed into production to see if the problem existed in that environment and it does.
Hope this helps. We really could use both of these applications as soon as possible.
I received your response regarding this issue in my email, but don’t see your response in this thread. However, just so I understand correctly, another user was experiencing something similar and the issue was identified due to a ticket automation that would run after the ticket was created, updating ticket properties. Therefore, triggering the “onTicketUpdate” event? I mean this makes sense and I can’t believe I didn’t think of that as a potential issue.
That being said, I have a number of ticket workflows that make changes to tickets after they are created. How would you suggest I move forward to obtain my desired result of being able to isolate the onTicketUpdate event only being triggered by an agent and not by a workflow? Cuz, I would hate to lose the functionality of the onTicketUpdate event for my current and future custom applications.
Thank you for your time and support with this issue. I know it has been a challenging one.
I have written an early reply and later deleted it because I needed to confirm couple of things to share accurate response. Looks like forum was smart that it triggered an email very fast
For example, there is a workflow configured that updates Priority when ever status is updated. That means product sees two updates of it’s ticket properties and tell your app the same. Which is why app senses 2 triggers.
While that is at the core of the problem, I am also looking for a solution.
From what I digged down and found out, all the product level events performed will have a special attribute (For example, event_id to be 0). At this point I am trying to learn from @Anand_Ganesan, who had a similar problem to find what those exact attributes are. The idea is, if those attributes are known, app can filter out product-level events and disallow duplicates.
