New and reassigned tickets: one triage status or two? (JSM)

Hi @Kent G

I always try to keep it to less statuses as possible, so I would prefer just one. However, I've worked with clients who want to track a separate status, so it would also depend on the reporting needs as you build your workflow.  

Regards,

Fabian

Hi @Kent G ,

Classic and interesting question. I give a different view of previous replies.

Using the field Group/Team allow you to trace correctly if the ticket is waiting for be assigned or is already assigned to a team, so no problem for this.

But if you use only one status:

• The second team could have difficulties on detect that a pre-existent ticket, previously in charge to a different team, has been now assigned to a second team. This could be the problem you can have.
• Second, you won't be able to detect easily how many times a tickets has jumped to a different team, and the inefficiences related to this

Generally, I prefer two statues.

In conclusion, the decision to use only one status or two, it depends if the changes between teams are frequent or only in rare cases.

Hope it helps

Hi @Kent G , @Fabian Lim and @Sam Njoroge have given you the two honest positions, and both are right for different shops. What is missing is the rule that tells you which one is yours, so here it is. It comes down to two questions about what a reassignment has to do in your setup.

The constraint behind the whole question: JSM's SLA engine only sees reassignment in one shape. The only assignee-based SLA condition is Assignee: From Unassigned. There is no start, pause or stop condition for "assignee changed from person A to person B," so a straight handover between two people is invisible to the SLA clock and, for the same reason, invisible to most queue logic. The SLA conditions are otherwise status-driven. (Atlassian's SLA troubleshooting KB is the reference for assignee-based conditions: https://support.atlassian.com/jira/kb/how-to-troubleshoot-slas-in-jira-service-management/)

So the two questions:

1. Does a reassignment need to touch the SLA clock? If a ticket bounced to a different group should restart or re-run a response goal, the engine needs an event it can see: either a status change ( @Matteo Vecchiato  second status) or the assignee going back to Unassigned so that From Unassigned can fire again.

2. Does "waiting for the new group to pick it up" need its own queue? Queue JQL can express assignee is EMPTY and assignee CHANGED AFTER -1d, because CHANGED works on the assignee field. It cannot express "Group/Team field changed," because CHANGED does not work on custom fields (https://support.atlassian.com/jira-software-cloud/docs/jql-operators/). So a reassignment is only queue-able if it either enters a status or clears the assignee.

The rule: if the answer to both is no, take Fabian's advice, one triage status, and recover reassignment churn later from the assignee history (the changelog records every assignee change, so time-in-status is not the only way to measure it). If the answer to either is yes, you need an observable event, and you have two designs:

• Two statuses (Matteo's design): clean, reportable in time-in-status, one extra transition to maintain.
• One status plus an automation that clears the assignee whenever the Group/Team field changes: keeps Fabian's status count, makes From Unassigned fire again for the SLA, and makes the "awaiting pickup" queue a two-clause JQL. The cost is that your groups must accept a moment of Unassigned on every handover, and the churn shows up in assignee history rather than in status reports.

If I were designing it for several groups sharing one space, I would pick the second for as long as the group count is small, and move to a dedicated status the day a manager asks for "time waiting for reassignment" as a report column, because at that point time-in-status is the only thing that answers cleanly.

Hi @Kent G 

One more option if SLA behavior is one of the things driving the decision between one or two triage statuses. I work at SLA Time and Report for Jira app. With our app, the SLA logic doesn’t have to depend only on adding another workflow status. For example, you can configure the SLA to reset when the responsibility changes, using conditions such as Assignee or Team, depending on the fields available in the project.

So if a reassigned ticket needs a fresh response or pickup target, the SLA can restart based on that change without necessarily introducing a separate “Awaiting Reassignment” status just for SLA tracking.

This can also help when several teams share the same service space but work different schedules. With a Multiple-scheduler SLA, the timer uses the current assignee’s work calendar and automatically switches to the new one when the ticket is reassigned.

That gives you another option: keep the workflow/status model as simple as the process allows, and handle the reassignment-specific timing logic separately in the SLA configuration.

Agree with @Fabian Lim unless reporting dictates it, fewer statuses is my preference as well.