Validating and Cancelling Timers between Tickets in the Zendesk Flow and CLAudia
Vitor Almeida
- Case Context
During the analysis of the behavior involving tickets #344975 and #344987, the following flow was identified:
10:21:01 — Ticket #344975 changed to Resolved and submitted CSAT.
10:21:25 — Ticket reopened after interaction (customer didn't respond to CSAT).
10:29:51 — Customer answers the CSAT and the ticket is changed to Closed.
Up to this point, the behavior adheres to the standard flow.
10:29:59 — Customer sends a new message (“HELLO”).
As ticket #344975 was already in Closed status, the system correctly creates a new ticket: #344987.
Subsequently, the following automatic shots occur on ticket #344987:
10:49:15 — Inactivity message (5-minute rule).
10:57:19 — Closing message (10-minute rule).
- Technical Diagnostics
From the time interval, it can be seen that the timers appear to have started even in the context of ticket #344975 and were still active after its closure.
When the ticket was closed at 10:29:51, the pending jobs weren't canceled. After the new message from the customer and the creation of ticket #344987, the routine remained active and was executed on the ticket that was linked to the same conversation at the time the timer expired.
The behavior indicates that the timers are tied to the conversation_id, and not to the specific ticket_id.
As the routines were not invalidated when the original ticket was closed, the shots originally planned for a closed ticket ended up being executed on the subsequent ticket of the same conversation.
- Problem Identified
- Timers are not canceled when closing the ticket.
- Jobs remain active even after changing status to Closed.
- There is no integrity validation between the original booking ticket and the ticket in effect at the time of execution.
The unique link to conversation_id allows cross-execution between different tickets from the same conversation.
- Improvement Proposal
4.1 Automatic Timer Cancellation
Whenever a ticket is changed to Solved, Closed status, all timers and pending jobs associated with it must be automatically invalidated.
4.2 Validation Before Job Execution
- At the time the timer is executed, the following must be validated:
- Whether the ticket_id originally associated with the job is still the same.
- Whether the ticket remains in an open status.
If any of these validations fail, the execution must be aborted.
4.3 Double Link (conversation_id + ticket_id)
Even using the same conversation_id, the timer must be explicitly linked to the ticket_id.
Message queuing and triggering must consider both identifiers, preventing routines initiated on one ticket from being executed on another ticket in the same conversation.
- Expected Result
With the implementation of the proposed validations:
- Timers don't migrate between tickets.
- Automatic messages are not improperly triggered on new tickets.
- There is greater integrity in the execution of asynchronous routines.
The behavior remains consistent with the standard flow, with additional consistency control.