How QA Teams Auto-Assign Reopened Tickets to the Right Developer
When a fix fails testing, the ticket reopens. If it lands unassigned, the developer's context is lost and someone has to track them down and hand it back manually.
Auto-assignment on reopen removes that step. The moment a ticket fails testing, it goes straight back to the person who already knows the history.
Where this fits in your workflow
As explained in Enhanced Automation Capabilities, rules can run on a Transition, which ties an action to one exact move between two statuses rather than to a status in general. This is the right place for QA handoffs: you do not want every way of entering In Progress to trigger a reassignment, only the move that comes from a failed test.
An important limit to plan around: a rule's action can set the assignee to a specific team member, but it cannot look up "the last person who worked this ticket" by itself. The scenarios below use the field that already tracks that, your ticket's Assignee history or a custom field you set when the ticket was first worked, as the value the rule routes back to.
Reassign to the original developer when a test fails
When QA reopens a ticket, by moving it from Testing back to In Progress, the ticket should return to the developer who last worked it, not sit in a general queue.
Allan fixes the checkout crash and marks the ticket Resolved. Megan tests it, but the page still crashes when a coupon is applied, so she reopens the ticket. Without a rule, the ticket sits in the queue until someone notices it, and Diego or Adele might pick it up without any context. With the rule, it goes straight back to Allan.
Where: on the transition from Resolved to Reopened.
Condition: tag Bug is present
Action: Assign the ticket to the original developer (Allan Deyoung).
Notify the developer at the same time
Reassignment alone does not guarantee the developer notices right away. Add a notification to the same rule so they know a ticket bounced back the moment it happens.
Allan has already started on his next ticket when Megan reopens this one. The ticket is assigned to him, but he is focused on other work and would not see it for hours. Because the checkout crash is High priority, the rule notifies him right away. Lower-priority tickets are still reassigned, but without the extra ping.
Where: on the transition, Resolved to Reopened.
Condition: priority is Urgent
Action: Assign the ticket to the original developer (Allan Deyoung), and send a notification to them.
Route a second failure to a senior developer
A ticket failing testing once is normal. Failing a second time is a signal that it may need a different approach. Use a tag to track the number of failures, and route accordingly.
After the first failure, Megan adds the tag Failed Twice to the ticket. Allan resolves it again, but the crash still appears in one case, so Megan reopens it a second time. Instead of sending it back to Allan for a third attempt, the rule routes it to Alex, who can review the approach.
Where: on the transition from Resolved to Reopened.
Condition: tag Failed Twice is present.
Action: Assign the ticket to a senior developer (Alex Wilber), instead of the original developer.
What this changes for a QA team
No reopened ticket sits unassigned: the handoff back to development happens the instant the status changes.
Context stays with the person who has it: the developer who already understands the bug gets it back, instead of a random pickup.
Fewer test-dev round trips lost: priority and notifications travel with the reassignment, so a reopened ticket does not quietly wait behind new work.
Ticket automation is available on the Professional and Leader plans. If you do not have Ticketing as a Service yet, try it for free.
Comments