At times, customers would report that the Time trigger automation rule was executed on incorrect tickets. For such cases, get the below details from the customer:


  • Screenshot of the rule including the rule ID
  • Screenshot of the ticket activities of the affected ticket


Sample scenarios:


1. The customer has a rule configured where when a ticket is in the Resolved status for xx hours then reopen it.



In the screenshot below, you will see that the ticket is in the closed status but the rule has been executed:



In Freshdesk, the current behavior is such that when a ticket is manually closed, the resolved_at timestamp would be the same as closed_at timestamp causing the automation to run. To avoid such cases, you could suggest the customer include another condition that says status=resolved.


2. The customer wants to change the group after 24 hours if certain conditions are met. Screenshot for reference:



But in the rule, they have set it as 12 hours so whenever these conditions are met, the group was changed. We can suggest the customer change it to 24 to work as per their business workflow.


3. If the ticket is FR violated, then unassign the ticket.


Rule configuration:



In the ticket, the agent has sent out a first response yet the rule was triggered.



Once you get all the details, navigate to the POD-specific Haystack application and add the below search query:


AND tickets=[


Log events:


[35637fcb-24e5-4105-857f-4745b5cc2265] [0731fca11b54baf78f0e3817] A=2084494 T= R=84000024836 conditions=["(helpdesk_tickets.frDueBy < ?) and (helpdesk_tickets.frDueBy > ?) and (helpdesk_tickets.group_id IN (?) )", "2021-11-24 21:14:47", "2021-11-24 20:14:47", [84000048658]],               negate_conditons=[" helpdesk_tickets.responder_id is not ? OR helpdesk_tickets.responder_id IS NULL ", nil], joins=[""], tickets=[14835, 14841, 14842, 14845] 


Get the Ticket XML data for the affected ticket and look for the frDueBy tag as below:


2021-11-25T01:52:01+05:30

false


There are 2 two tags called frDueBy and fr-escalated.


When you have the condition Hours since First response due (is or greater than), what the condition does is, it checks if the current time is greater than the frDueBy time(the date time field above). Since it is comparing current time at some point the time will be equal to or greater than.


Ticket created -  Dec 24 5:52 PM

frDueBy time - Dec 25 1:52 AM


Now the supervisor has ran at 2:44 AM (current time) greater than 1:52 AM. So according to the rule configuration the condition is satisfied and executed.


This is because everytime the hours since condition would be checked with the current time. To avoid this, there should be some kind of status check to make sure the rule is not running on first responded tickets.