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.EnvironmentJira Service Management CloudWorkforce enabledTicket assignment based on Team, Schedule, Availability, and CapacityIssueWorkforce 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:A new ticket is created.Team = L1 Support.Workforce correctly assigns the ticket to an available L1 agent.The ticket is later escalated to L2 Support.An automation clears the Assignee, updates the Team field to L2 Support, and saves the issue.We expected Workforce to assign an available L2 agent.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 behaviorWe expected Workforce to evaluate the new Team and perform another assignment whenever:the Assignee is empty, andthe Team changes to another Workforce-managed team.QuestionsIs Workforce intentionally designed to assign an issue only once during its lifecycle?Is there any supported way to trigger Workforce to perform another assignment after a Team change?Is this a known limitation, or is it considered a bug?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.

Community
Q&A
Jira Service Management
Questions
Workforce doesn't reassign tickets after Team changes

Workforce doesn't reassign tickets after Team changes

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:

A new ticket is created.
Team = L1 Support.
Workforce correctly assigns the ticket to an available L1 agent.
The ticket is later escalated to L2 Support.
An automation clears the Assignee, updates the Team field to L2 Support, and saves the issue.
We expected Workforce to assign an available L2 agent.
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

Is Workforce intentionally designed to assign an issue only once during its lifecycle?
Is there any supported way to trigger Workforce to perform another assignment after a Team change?
Is this a known limitation, or is it considered a bug?
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.

2 answers

2 accepted

3 votes

Answer accepted

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!

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Tuncay,

Thank you for the detailed explanation and for clarifying that this is expected behavior rather than a bug.

I really appreciate the insights and the suggestion regarding SnapAssign. Unfortunately, our goal is to avoid using additional Marketplace apps if possible, so we're trying to solve this with native Jira capabilities.

I'll also submit this as feedback to Atlassian, since multi-stage routing would be a valuable enhancement for our use case.

Thanks again for your help!

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

0 votes

Answer accepted

Hi @Jade Zavitoski,

That's expected rather than a bug. Workforce routing runs at intake. It assigns when a new item arrives with a team set, and it doesn't re-evaluate when the Team field changes on an existing issue, so clearing the assignee on the L1 to L2 hop won't re-arm it.

The native way to cover the escalation is Jira automation, not Workforce. You already have the rule that clears the assignee and sets Team to L2, so add an Assign issue action to it, scope the pool to your L2 agents by group or project role, and set the method to Balanced workload (it assigns to whoever has the fewest open issues, as long as they have Assignable User permission in the project).

Where it stops short of Workforce: Balanced workload counts open issues, not shift or availability, so an off-shift agent can still be picked. If availability-aware re-routing is what you actually need, native automation won't replicate that, and it's worth raising with Atlassian as multi-stage routing feedback.

https://support.atlassian.com/jira/kb/jira-automation-rule-to-auto-assign-issues-based-on-role-or-group/

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Gabriela,

Thank you for the clarification and for explaining how Workforce routing behaves in this scenario.

I am actually trying to solve this using Jira Automation. However, one challenge we have is that some agents may be off shift, and the native Balanced workload assignment doesn't take agent availability into account.

That's why we were hoping Workforce routing could be triggered again after changing the Team.

Thank you again for your explanation and for taking the time to help!

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Native automation can't see Workforce's availability, so you have to build the shift logic into the rule yourself.

To do it without an app, branch the escalation rule on the current time and send each branch to only the agents on that shift. In the rule that clears the assignee and sets Team to L2, add If/else blocks keyed off {{now.format("HH")}} (the hour in 24h), one block per shift window. Inside each, put the Assign issue action set to Balanced workload and scope the pool to just the L2 agents on that block, either a per-shift group or a typed-in user list. Set the action's JQL restriction so the balancing only counts L2 open issues.

Mind the timezone here. {{now}} won't necessarily resolve to your local zone, so test the hour boundaries before you trust the handoffs.

That gets you shift-aware routing on the L2 hop natively. What it won't catch is someone taking ad-hoc time off mid-shift the way Workforce's live availability does — you'd be keeping the per-shift group current by hand.

If you're already running on-call schedules under JSM Operations, there's a second route: assign to whoever's currently on call. Pulling that responder into the Assignee field isn't native to automation, it goes through the Operations API, so it's more plumbing than a plain rule.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Suggest an answer

Was this helpful?

Thanks!

Jira Service Management

DEPLOYMENT TYPE

CLOUD

PRODUCT PLAN

PREMIUM

Forums

Q&A

Community resources

Support

Top groups

Community resources

Support

Learn

Community resources

Support

Events

Community resources

Support

Workforce doesn't reassign tickets after Team changes

Environment

Issue

Expected behavior

Questions

2 answers

2 accepted

Suggest an answer

Was this helpful?

Thanks!

DEPLOYMENT TYPE

PRODUCT PLAN

TAGS

Atlassian Community Events