Before turning on Workforce Management: what I'm thinking through first

[Maximiliano Javier Julio]

I haven't activated WFM yet, but now that it's GA on Premium and Enterprise, I've been thinking through how it lands on a service space that already has years of JSM operations behind it.

Here's what's on my list before flipping it on:

1. Overlap with existing Operations features. JSM already has on-call scheduling and escalation policies built in. WFM adds its own shift scheduling and availability tracking on top. I haven't found a clear answer yet on whether these are meant to work together or whether WFM effectively replaces the old on-call setup for teams that adopt it. I saw someone else in the Community ask this same question on the GA announcement thread, so I don't think I'm the only one unclear on it.
2. Automation rules that assign blind to capacity. If a space already has rules that auto-assign tickets to specific agents or queues, those rules don't know anything about the new capacity thresholds or availability status unless they get rebuilt around WFM's routing logic. That's real rework, not a toggle.
3. Who owns keeping availability accurate. The intelligent routing only works as well as the availability data behind it. If marking yourself available or on a break becomes one more thing agents forget to do, the routing quietly degrades without anyone noticing until tickets start landing on the wrong desk.
4. Schedules without an end date. Someone flagged this on the announcement thread too: schedules currently need an end date, which is awkward for services that run 24/7 across rotating day and night shifts indefinitely. Worth checking if that's changed since GA.

If anyone has WFM running already on a space with a mature on-call setup, I'd like to compare what actually happened with the overlap versus what I'm guessing here.

[Sami Shaik · Accepted solution]

Hi @Maximiliano Javier Julio ,  good timing: I ran a controlled WFM test on a live Enterprise sandbox this week, timestamps and all, so I can answer some of this from observation rather than guessing. Taking your concerns in order

The finding that reframes most of your list first: WFM routing is schedule-gated. In my test, four agents sat Available with free capacity and a Team on the request, and nothing routed, because nobody was on an active shift. Moved the shift to cover the current time, and routing fired instantly. Four keys, all at once: Team on the request, availability, free capacity, and an active shift. The schedule is the heartbeat; availability is only an override within it.

On the availability dependency: the gate above actually softens this worry. Your rota drives who is assignable; agents flipping themselves Available outside a shift changes nothing, and an agent forgetting to update availability matters only within their shift. One trap though: default availability starts at Unavailable, so set the default to Available at go-live or nothing routes on day one even with perfect schedules.

On rebuilding capacity automations: think of it as layering, not rebuilding. WFM never picks the team; your existing automations (or humans) still set the Team on the request, then WFM picks the person within it using per-agent capacity you configure per team. Assignment-balancing rules become redundant; threshold-alert rules stay useful. If a request cannot be routed, it lands in an unassigned queue, make watching that queue part of the rollout.

On on-call overlap: honestly, nothing I saw in-product connects WFM schedules to on-call rotations; they are parallel scheduling surfaces today. I would plan them as such and avoid duplicating the same rota in both by hand until Atlassian says otherwise.

On 24/7 schedules and end dates: this is the one I have not stress-tested; my shifts were short and manual. There is a CSV bulk import for shifts which is likely your friend for continuous coverage, but test the recurrence behaviour in a sandbox before trusting it, that is exactly the kind of edge my first run showed the product hides quietly.

I wrote the full lab log up with screenshots and the go-live checklist here if the detail helps: WFM article. And when you do enable it, I would genuinely value your overlap findings back on this thread, between your mature-instance rollout and my controlled test, we would be mapping this feature better than the docs currently do.

[Jean Horn]

Hi @Maximiliano Javier Julio !

Thanks for sharing such a detailed pre-activation breakdown for Jira Service Management (JSM) Workforce Management (WFM)! You’ve nailed the exact operational risks that teams face when turning this on in a mature JSM environment.

Here are a few quick takeaways and practical steps based on what you outlined:

• WFM vs. On-Call Operations: They serve completely different purposes (daily queue coverage vs. incident paging). Make sure to define clear governance upfront so agents know which schedule to follow for what scenario!
• Legacy Automation Rules: WFM smart routing won't automatically capture tickets assigned by legacy automation rules. To make routing truly capacity-aware:
  1. Go to Project Settings > Automation
  2. Audit rules that assign tickets directly or route to specific queues
  3. Rebuild or adjust critical rules to ensure they align with WFM routing
• Agent Availability Discipline: Since routing relies on real-time availability status without native fail-safes, build an operational check into your team's runbook to prevent ticket dumping on available agents.
• Shift Schedules End Dates: Before launching in production:
  1. Set up a test shift without an end date in a sandbox or non-prod space
  2. Verify how the WFM surface handles continuous rotations compared to On-Call schedules

It’s definitely a partial migration rather than a simple toggle switch, but addressing these points before go-live will save you a ton of rework!

Hope this helps!