Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Workforce doesn't reassign tickets after Team changes

Jade Zavitoski
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 2, 2026

Hello,

I'm experiencing what appears to be a limitation (or possibly a bug) with Jira Service Management Workforce, and I'd like to confirm whether this is expected behavior.

Environment

  • Jira Service Management Cloud
  • Workforce enabled
  • Ticket assignment based on Team, Schedule, Availability, and Capacity

Issue

Workforce successfully assigns a ticket the first time it is routed to a team.

However, if the ticket later moves to another stage in the workflow and the Team field is changed (either manually or through Automation), Workforce does not perform a new assignment.

For example:

  1. A new ticket is created.
  2. Team = L1 Support.
  3. Workforce correctly assigns the ticket to an available L1 agent.
  4. The ticket is later escalated to L2 Support.
  5. An automation clears the Assignee, updates the Team field to L2 Support, and saves the issue.
  6. We expected Workforce to assign an available L2 agent.
  7. Instead, no new assignment occurs.

We also tested:

  • Clearing the Assignee before changing the Team.
  • Removing and setting the Team again through Automation.
  • Triggering the automation after the Team update.

In all cases, Workforce only performs the initial assignment and never assigns the issue again.

Expected behavior

We expected Workforce to evaluate the new Team and perform another assignment whenever:

  • the Assignee is empty, and
  • the Team changes to another Workforce-managed team.

Questions

  1. Is Workforce intentionally designed to assign an issue only once during its lifecycle?
  2. Is there any supported way to trigger Workforce to perform another assignment after a Team change?
  3. Is this a known limitation, or is it considered a bug?
  4. If this behavior is expected, are there any recommended best practices for implementing multi-stage routing (for example, L1 → L2) while still using Workforce?

Thank you in advance for your help.

1 answer

1 vote
Tuncay Senturk _Snapbytes_
Community Champion
July 2, 2026

Hi @Jade Zavitoski 

What you're seeing looks like expected behavior, not a bug

Workforce automatic routing is designed for new work items at initial routing time. Atlassian's docs describe it as picking an agent when a new item comes in with a team assigned, there's no mechanism to re-evaluate routing when the Team field changes later, even if Assignee is cleared.

Escalation / multi-stage routing (L1 → L2) was also called out in the WFM AMA as not part of the GA release, so your use case is a known gap rather than misconfiguration. (Please take it with a pinch of salt)

There isn't a supported way to re-trigger Workforce assignment after a Team change. 

For automated L1 → L2 routing: you'd need something that listens to issue updates. For example, we built SnapAssign for exactly this, it can watch the Team field and assign when it changes (with "assign only if unassigned" so it works alongside your automation that clears the assignee first). You can keep WFM for initial routing and use SnapAssign for re-assignment on escalation, or use SnapAssign for the full flow.

Happy to walk through a setup if useful. Also worth logging this as feedback with Atlassian  multi-stage routing is clearly a common need.

 

Best!

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
TAGS
AUG Leaders

Atlassian Community Events