Forums

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

JSM Workforce Management: the lab log. 17 minutes of nothing, then everything ๐Ÿงช

Workforce Management went GA in JSM this summer: native schedules, live availability, capacity tracking, and automatic routing, no third-party tools. The announcement makes it sound like a toggle. So I spent an evening actually turning it on, in a sandbox, with a real team, and kept a log. The most useful thing I learned came from seventeen minutes where nothing worked at all ๐Ÿ‘‡

Scope: JSM Cloud, Premium and Enterprise. Everything below observed in-product on 10 August, timestamps and all. One caveat straight from the docs before you plan anything: WFM is explicitly not HIPAA compliant.

The lab log โฑ๏ธ

Early evening: finding it. A new Workforce entry sits in the JSM project sidebar, wearing a New badge.

wfm-fig1-sidebar.png 

The landing page pitches the idea and, boldly, industry benchmarks: better first-contact resolution, less reassignment, higher utilization. Ambitious numbers to print on your own front door. Noted for later re-inspection ๐Ÿ˜„

 

wfm-fig2-landing.png

 

Setup: three honest traps before anything works. Setup is genuinely quick, but the wizard hides decisions worth making slowly:

  1. WFM runs on Atlassian Teams, not Jira groups. If your agents live in groups (most mature sites), the wizard offers to convert groups into teams. That is a real org-structure decision dressed as an onboarding step: those teams exist beyond this feature. Convert deliberately, not casually.

wfm-fig4-converter.png

  1. The 15-team cap counts invisible teams. Teams linked to your space without eligible members still consume the limit. Audit what is already linked before you connect.
  2. Default availability starts at Unavailable. Enable everything correctly and route nothing forever, because nobody is available until someone says so. Set the default to Available (or brief your agents to set themselves) as part of go-live, not after the first confused hour.

The configuration anatomy. Once teams are connected: default availability, per-team capacity (max active work items per agent), and the Auto assign toggle. Auto assign off is a genuinely nice middle mode: WFM recommends agents in the assignee picker but a human still clicks. And one info banner on this page turns out to be the entire mechanic, though I did not realise it yet: work assignment starts when a Team is added to a request, and requests that cannot be assigned go to an unassigned queue.

wfm-fig5-enabled.png

21:03, the first test: nothing happens. Request created. Team field set (I even wired the automation every real org will need: on creation, set Team). Four agents, all Available, all idle, capacity five each. Assignee: empty. Second test, manual Team edit this time: empty again. Everything green, nothing routed ๐Ÿคจ

The realisation. The Schedules page had been telling me the answer the whole time: Active agents: 0. My one test shift started at 21:30. All four agents were Available, and none of them was on shift.

wfm-fig6-schedules.png

21:20, inside an adjusted shift: everything happens. Shift time moved to cover now. New request, Team set, and the assignee filled in on its own. Another request: routed to the next agent. Capacity utilization now shows two active work items, two agents at 20 percent, badged Optimal ๐ŸŽ‰

wfm-fig7-capacity-after.png

 

What the evening proved ๐ŸŽฏ

WFM routing needs four keys, all turned at once: a Team on the request, an active shift, availability, and free capacity. Same agents, same availability, same capacity, same Team field at 21:03 and at 21:20. The only variable that changed was the shift being live, and that flipped routing from dead to instant. The schedule is the heartbeat. Availability and capacity are filters within it. The Team field is the ignition. An Available agent with no active shift receives nothing, which is exactly what will confuse every service manager on day one, and no announcement says it this plainly.

And notice the architecture: WFM never decides which team owns a request. Something else does that (your automation rules, your triage human), and WFM picks the person within the team. Deterministic rules route the work; WFM routes the workload. If you already have assignment automations, they do not collide with WFM, they feed it.

Before your go-live, the checklist โœ…

  • Decide the groups-to-teams conversion deliberately, with whoever owns your org structure
  • Audit already-linked teams against the 15-team cap
  • Set default availability to Available, or brief agents that the first move is theirs
  • Wire one automation: on request creation, set the Team (WFM does nothing until something does)
  • Build schedules that actually cover your support hours, because no shift means no routing, regardless of anything else
  • Find your unassigned queue and make it someone's job to watch it
  • Start with Auto assign off for a week: recommendations without commitment is a gentle rollout

If you switch it on, I would genuinely like to hear one thing in the comments: how long between "enabled" and "first correctly routed request" on your site. My honest number, including the seventeen confused minutes, was about twenty one. Beat it ๐Ÿ˜„

Sources, all verified 10 August 2026: What is Workforce Management (Atlassian support), the GA announcement, plus the full evening run on a live Enterprise sandbox, timestamps in the figures.

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events