Every product manager I've ever met has at some point opened a spreadsheet, stared at 247 rows of "great ideas," and quietly wondered if they should just start a llama farm in Wisconsin instead.

I get it. The pain isn't a lack of ideas — it's the gulf between "this would be amazing" and "this is in production." For years, product teams have lived in one tool to think, another to plan, a third to spec, and a fourth to actually build. By the time an idea reached engineering, half its context had evaporated like coffee in a sprint-planning meeting.

That gulf is exactly what Atlassian closed when they wired Jira Product Discovery directly into Jira Software. And as a Solutions Partner who spends a healthy chunk of every week watching teams discover this connection for the first time, I can tell you — the reactions range from "wait, that's it?" to "where has this been all my life?"

Let me walk you through it.

JPD: where chaos earns its way onto the roadmap

Jira Product Discovery is Atlassian's home for the messy, beautiful, pre-roadmap chaos. It's where customer feedback gets captured, ideas get scored, opportunities get compared, and roadmaps get built. Think of it as the strategy whiteboard your team always wished it had — but one that doesn't get erased on Friday afternoons.

Inside JPD, you're working with ideas, not tickets. You can tag them, score them with custom fields, prioritize them with RICE or ICE or your own brand of arithmetic alchemy, and roll them up into views tailored for executives, customers, or that one stakeholder who only wants to see things in dark mode.

Jira Software: where ideas grow up and ship

Jira Software, on the other hand, is the engine room. It's where epics get broken into stories, stories get broken into tasks, and tasks get broken into a developer's afternoon. Sprints, backlogs, boards, releases, dependencies — it's the operational machinery of getting code out the door.

Either tool is powerful on its own. Together, they're a different animal entirely.

The magic happens in the Delivery panel

Inside any JPD idea, there's a Delivery panel on the right side. From that panel, you can either create a brand-new epic or task in Jira Software, or link to one that already exists. The link is bidirectional — JPD knows about Jira, and Jira knows about JPD.

A few details I love:

• One idea, many epics. You can link a single idea to multiple epics across multiple Jira Software projects. Big initiatives don't get squeezed into one team's lane.
• Your math, your call. Choose your delivery progress calculation — by issue count or by story points. Either way, JPD displays a progress bar inside the idea that reflects what's actually happening in delivery.
• Context comes along for the ride. Embed the idea's description and fields straight into the new epic, so engineers don't have to swivel-chair between tools to understand why they're building what they're building.
• Cloud and Data Center, side by side. Premium plan users can connect JPD to Jira Data Center instances — a huge win for enterprises straddling Cloud and on-prem.

Why this matters — the trusted-advisor take

Here's where I'll pull on my Avaratak hat for a moment, because the integration isn't just a feature. It's a different operating model.

When discovery and delivery live in separate tools, you get something I call "context loss tax." Every hand-off costs information. A PM writes a brilliant idea doc; an engineer reads a stripped-down ticket; somewhere in between, the why goes missing. Multiply that by a year of work, and you've built a roadmap of features nobody quite remembers asking for.

When the two are connected, the why travels with the work. An engineer opening a Jira epic sees the linked idea, the original customer insights, the priority score, and the strategic context — without leaving Jira. A PM watching the JPD idea sees real-time delivery progress without DM'ing the engineering manager for the third time that week.

That's not just convenience. That's organizational memory.

Three patterns we recommend at Avaratak

Three patterns I find myself recommending to clients constantly:

One idea, many epics. If you're shipping something cross-functional — say, a billing redesign that touches web, mobile, and backend — link one JPD idea to one epic per team. The delivery progress bar gives leadership a single number to watch instead of three Slack threads to chase.

Insights before commits. Use Jira Service Management as an insights pipeline into JPD. Customer feature requests flow from JSM into JPD as raw signal. Nothing moves to Jira Software until the idea has earned its way onto the roadmap. The result: a clean Jira backlog where every item is genuinely committed work, not aspirational debris.

Embed JPD views in Confluence. Stakeholders rarely want to log into another tool. Drop a JPD roadmap view into a Confluence page, wrap it in narrative context, and you've got a living strategy doc that updates itself.

The forward-thinking bit

The trajectory here is worth paying attention to. Atlassian is steadily collapsing the seams between strategy, planning, and execution. JPD ideas now show up directly in Jira Plans. AI features are being layered onto insights capture and roadmap synthesis. The tools are evolving toward something that feels less like a stack and more like a single fabric.

For teams still running discovery in spreadsheets and delivery in Jira, the migration is cheaper and easier than most expect. The hard part isn't the tooling — it's the habit change of letting ideas earn their way to delivery instead of arriving there by political momentum.

The bottom line

If your roadmap currently lives in three documents, four tools, and the heads of two senior PMs who happen to be on vacation, the JPD-and-Jira-Software pairing is one of the highest-leverage moves you can make this quarter. Less context-switching, more context-keeping. Less "what were we building again?", more "when does this ship?"

That's the kind of clarity we love helping our clients find at Avaratak. If your team's discovery-to-delivery flow feels more like a game of telephone than a relay race, we'd be happy to chat. We bring the playbook. You bring the ideas.

Picture this. You are three coffees deep, juggling six browser tabs, copy-pasting from a doc into a ticket, and trying to remember which Slack thread had "the answer." Meanwhile, the AI tool your company bought sits politely on the side of your screen like a well-trained parrot — waiting for you to spell out what you already know.

That is the moment Atlassian just declared over.

On May 6, the Teamwork Collection team rolled out a wave of updates at Team ’26 in Anaheim, and I have spent the past few days reading the announcement, watching the demos, and mapping it back to what our clients at Avaratak Consulting are actually trying to solve. The short version: AI agents are getting a desk, a badge, and a real Jira ticket. The longer version is worth your time, so let me walk you through it.

Agents in Jira: Hire, Don’t Just Prompt

The headline change is that Agents in Jira is now generally available. Translation in plain English: AI agents can own work items the way your teammates do. They get assigned. They get @mentioned in comments. They get automatically pulled in when a ticket moves into a designated status. Every action they take is logged with a full audit trail, admins control which agents are allowed to run where, and your team picks the right agent for the right job.

That last detail is the one I keep coming back to. Atlassian’s first-party Studio agents now work alongside third-party agents your team already trusts — Amplitude, Canva, Cursor, Figma, Gamma, GitHub Copilot, and more. Your stack does not have to shrink to fit the AI. The AI fits the stack.

This is the quiet shift from "AI as a feature bolted on" to "AI as a coworker with the same accountability as everyone else." For our clients in regulated industries, the audit trail alone is the kind of thing that makes compliance officers stop holding their breath.

Confluence Pages That Tag Agents Like Teammates

Third-Party Agents in Confluence (now in open beta) extends the same idea into your knowledge base. You can @mention agents from Lovable, Replit, Databricks, and Gamma directly on a page. They read the context. They take action. The idea moves from doc to outcome without anyone opening a new tab.

The pattern here is worth pausing on. Atlassian is not trying to be the only AI in the room. They are trying to be the room where every AI shows up, brings its skills, and works on the same source of truth. That is a meaningfully different bet than the "buy our agent or buy theirs" stance most platforms are taking — and it lines up with how the best teams actually work. They pick the tool for the job, not the other way around.

Remix with Rovo: The "Why Did Nobody Read My Doc?" Solution

Be honest. How many beautifully written Confluence pages have you posted that nobody read past the second heading?

Remix with Rovo (now in beta) lets you select content on a page and transform it into a chart, a timeline, an infographic, a geo map, an org chart, a quadrant, or a flip card. Your original content stays put. The visual version sits alongside it, ready for the audience that prefers shapes to paragraphs. Atlassian notes that Confluence pages with visual elements are nearly twice as likely to be read by a wider audience. That tracks with everything we see in client engagements. The information was never the problem. The format was.

Confluence Slides: The Deck Builds Itself

Confluence slides (in beta this month) is the one I expect to break the most calendars. You ask Rovo to create or edit slides, and it pulls context from across your Atlassian apps via the Teamwork Graph — slide structure, content, charts, graphs, the works. You can present from inside Confluence without ever opening that other slide tool whose name everyone knows. For consulting work and steering committees, this turns a two-hour ritual of "wrangle the page into a deck" into roughly ten minutes of cleanup. That is not productivity theater. That is a real Tuesday morning handed back to you.

Create with Rovo in Jira: Closing the Loop

Create with Rovo in Jira (also in beta) turns Confluence docs, meeting summaries, and email threads into structured Jira work items. Atlassian’s stated benchmark is that teams start up to 30% faster with less coordination overhead. I would want to validate that against our own client data before quoting a percentage at a boardroom, but the principle is exactly right. The gap between "we agreed on this in the meeting" and "there is a ticket for it tomorrow" is where most projects quietly bleed time.

Agent Briefings in Loom: Show, Don’t Type

This one made me grin. Agent briefings in Loom (coming soon) let you record a walkthrough of your requirements, designs, or feedback. What you say, what you show, what you click — all of it gets captured as multimodal input and translated into a structured prompt that an agent can act on. Loom then generates a suggested action plan that becomes Jira work items in one click.

Anyone who has ever tried to write the perfect prompt already knows the secret: a two-minute video of you pointing at the screen is worth a thousand carefully-worded paragraphs. Atlassian just gave that intuition a product.

Bug Reporting With Loom and Jira: From Observation to Fix

Now generally available, bug reporting with Loom and Jira lets anyone record a Loom that captures device info, console logs, and network data in the background. Loom then packages all of that developer context into a Jira ticket that can be assigned directly to Rovo Dev to draft a fix automatically.

That is the full loop closed: a non-technical user reports a bug, the system gathers the technical evidence, and an AI takes the first crack at the patch. Your human developer gets a head start on a real problem instead of a help-desk ticket that says "the thing is broken on the page with the colors."

Why It All Holds Together: The Teamwork Graph Underneath

Every update I just walked through works because Jira, Confluence, and Loom share the same foundation: the Teamwork Graph. Agents assigned in Jira pull context from Loom recordings. Bug reports become tickets Rovo Dev can act on. Remix turns a page into a presentation. A Loom becomes a brief that generates structured work.

This is the part I want every leader to internalize. The value is not in any single feature. The value is in the fabric underneath them. Once your work, your knowledge, and your communication share a graph, every AI you plug in becomes more useful than the last.

The Avaratak Take

We are advising clients to start small and start now. Pick one team. Turn on Agents in Jira. Pair it with Remix in Confluence. Watch what happens to your cycle time over a sprint or two. That is not a moonshot. That is a Tuesday with intention.

If you are an Atlassian customer wondering how to turn AI from a novelty into operating leverage — with the kind of thoughtful rollout that respects your governance, your culture, and your team — our door is open at avaratak.com. As an Atlassian Solution Partner, we take the trusted-advisor role seriously: integrity first, your interests first, and the shiny stuff only when it earns its place in the stack.

The chatbot got a real job. The only question left is whether your team is ready to be its manager.

Today is Mother's Day, and I am sitting at my kitchen counter with a coffee that has gone cold twice already because, as it turns out, I have spent the last forty minutes trying to find the right words to thank my mother for skills the entire enterprise software industry has spent the last two decades trying to sell back to her.

Let me explain.

Somewhere around the time I was eight years old, my mother kept track of three school schedules, one carpool roster, two parent-teacher conference calendars, the dog's vaccination dates, my grandfather's medication refills, who needed clean soccer socks by Tuesday, and the precise location of every birth certificate in the house. She did this with no software. No dashboard. No automation rule. No agent. Just a spiral notebook, a wall calendar with handwriting tilted slightly to the right, and an unshakable mental model of how the household actually worked.

In the language of my industry, what my mother was running was a real-time, multi-stakeholder, cross-functional, mission-critical operations platform with five-nines uptime and zero downtime tolerance. We just called it “Mom.”

So today, on this Mother's Day, I want to do something that is overdue. I want to look at the Atlassian ecosystem — the one I work in every day with my clients at Avaratak Consulting — and quietly admit how much of it is just “Mom” with a UI.

The Original Backlog

Jira's whole purpose is to capture work that needs doing, prioritize it, assign it, track it, and keep it visible. My mother did this in her head, in real time, while making dinner.

“Permission slip due Friday.” Captured. “Dentist Tuesday at 3:30. Switch carpool with the Hendersons.” Prioritized. “Older one needs new cleats before Saturday's game; younger one needs poster board for the science project by Wednesday.” Assigned (to herself, naturally) and tracked.

The terrifying part? She also did dependency mapping without ever using the word. She knew the cleats had to happen before the game, which had to happen before the laundry, which had to happen before church, which had to happen before grandma's visit, which determined whether the carpet got vacuumed Saturday night or Sunday morning. That is not a backlog. That is a roadmap.

The Original Confluence

Every household runs on tribal knowledge. Where the spare key lives. The exact way Aunt Linda likes her coffee. Which uncle to never seat next to which cousin at Thanksgiving. The phone number for the plumber who actually answers on weekends.

This is institutional memory. In our world, we would build a Confluence space, write a runbook, mark it as canonical, and hope someone updates it. In Mom's world, it lived in her head with perfect retrieval and a freshness date that never expired. And when you needed it, the latency was zero — you just asked, and the answer came back, often with the helpful addendum, “and don't forget to bring something to your aunt, she'll be hurt if you don't.”

That is not just documentation. That is documentation with empathy baked in.

The Original Standup

Every dinner table in America has hosted a daily standup since long before Atlassian was founded. What did you do today? What are you working on tomorrow? What is blocking you? The format had not been invented in agile yet, but my mother had been running it for years.

The genius was not the questions. The genius was that the questions came with food, attention, and follow-up. “You said you'd talk to your teacher about the math grade — did that happen?” That is not a status update. That is a retrospective.

The Original Automation

Sunday meal prep. Lunch packing on autopilot at 6:47 a.m. The system that ensured the laundry hamper never overflowed because Tuesday and Saturday were sacred. These were not chores. They were CI/CD pipelines built out of muscle memory and quiet intention. Something would trigger, the routine would fire, and life kept shipping on time.

What is wild is that my mother understood the principle that took our industry decades to learn: automate the predictable so you can give your full attention to the unpredictable. The unpredictable, in her case, was usually one of us. And she was always there when we needed her — because she had already automated everything that did not.

The Original Compass

Compass is Atlassian's home for the catalog of services your team owns: who runs what, what depends on what, what is healthy, what is drifting. Mom had a catalog like that, only the services were us. She knew which kid had a dentist appointment, which one was on the verge of a cold, which one was navigating a tough week at school, and which one had been suspiciously quiet at dinner. She tracked dependencies. She watched health scores. She paged herself in when something was off.

We pay for software to do that kind of observability now. She did it because she loved us.

The Original Trusted Advisor

This is the one that lands hardest for me, because at Avaratak Consulting, trusted advisor is the phrase we put at the center of how we serve our clients. We talk about putting client interests first. We talk about integrity. We talk about being the person someone calls when they don't know what to do.

That is just what Mom did. Every day. Without a contract.

She gave advice that was not always what I wanted to hear, but was almost always what I needed to hear. She held the long view when I was stuck in the short one. She told me the truth even when it was inconvenient for her. And she did it without ever once sending an invoice.

If there is a model for how a consultant should show up for a client — calm, clear-eyed, prepared, generous, and honest — it has been sitting at a kitchen table somewhere this whole time.

The Avaratak Take

Today is a good day to thank the women who built the original collaboration platforms, before platform was a word any of us used in this context. The mothers, the grandmothers, the aunts, the chosen-family caretakers, the stepmoms, the friends who became mothers to your kids when you needed them to. The whole quiet army of people who run the workflows that keep families functional.

If you are in the Atlassian ecosystem the way we are, you already know how much intentional design it takes to keep a system running well. Every Jira automation rule, every Confluence space, every Compass component represents someone caring enough to make the system better for the next person who touches it.

Mothers have been doing that work for as long as families have existed.

So if you have a few minutes today, put down the laptop. Skip the standup. Let the backlog wait. Call your mom. Or text her. Or just sit with the memory of her if she is no longer here. Whatever the right gesture is for you — make it.

The rest of the work will be there tomorrow, and now you know it always was.

Happy Mother's Day from all of us at Avaratak. We hope today is gentle on you, generous to you, and full of people who love you the way the moms in your life have loved.

At Avaratak Consulting, we partner with teams to bring the same quiet competence, attention to detail, and care for people that the best moms in our lives modeled — applied to your Atlassian environment. If you would like a trusted advisor in your corner, we would love to hear from you at avaratak.com.

I'm typing this from a window seat at 35,000 feet over the Mojave, with a half-eaten pretzel in my lap and a Team '26 lanyard still hanging off my carry-on like a souvenir I forgot to take off. Three days in Anaheim, a notebook full of half-legible scribbles, and the slow, satisfying realization that this is going to be a Team conference we'll be referencing for a while.

The Day-1 hallway had a different texture than past Team events. The Wednesday founder's keynote landed with a thesis instead of a feature list. And by Thursday afternoon, I was in a partner roundtable where three different Solution Partners independently described the same shift in customer conversations — “they stopped asking if AI works and started asking how to scale what's already shipping outcomes.”

So before this all gets memory-holed by Monday standups and email triage, here are the patterns I'm taking back to Avaratak's clients — the ones that survived the flight home.

Atlassian stopped trying to be the AI

This is the strategic move I keep returning to. By opening up the Teamwork Graph through the new Teamwork Graph CLI and the Teamwork Graph tools in Rovo MCP Server, Atlassian effectively said, out loud, that they don't need to be the only AI vendor in your stack. They want to be the context layer underneath whichever AI vendor your stack runs on — Claude, Cursor, Gemini CLI, GitHub Copilot, the long tail of internal tools your team is already paying for.

That is a remarkably honest position for a public company to take in 2026. It's also the more durable one. Frontier models are commodities now. Anyone can rent intelligence by the token. The thing nobody can sell you is your own institutional memory — which decisions you made, why you made them, who owns what, and what good looks like at your shop. The Teamwork Graph, with more than 150 billion connections and 12 billion changes flowing through it every day, is the closest thing the industry has to an architectural answer for that.

If you're a customer, that means the Atlassian conversation just got bigger than “which Atlassian apps are we using.” It became “how rich is our context layer, and which AI tools are running on top of it.” That reframing changes the kind of roadmap you ought to be writing this quarter.

The cadence shift is the bigger story

Every Atlassian conference for the past decade has followed the same rhythm: save up the big announcements, drop them on a Wednesday morning, take a victory lap. That model is officially retired. Mike Cannon-Brookes said it from the stage and, to Atlassian's credit, the product teams immediately backed it up — they're shipping in public, every day, alongside customers.

The implication for everyone else is real. “Set it and forget it” is no longer a viable Atlassian admin strategy. Release notes are now a weekly read, not a quarterly one. The companies that come out ahead in the next twelve months will be the ones who treat the Atlassian release stream the way mature engineering teams treat dependency updates — continuous, small, deliberate, and always tied back to a clear internal owner.

That's a real ask of internal IT and Center-of-Excellence teams. It's also the precise gap that good Solution Partners are built to fill.

Agents in Jira hit GA, and governance came with it

The single most underrated headline of the week: Agents in Jira moved from open beta to generally available, and the governance story arrived with it. You can assign Jira work items to Rovo agents and to third-party agents from Amplitude, Canva, Cursor, Figma, Gamma, GitHub Copilot, and others. Every interaction is auditable, traceable, and governed inside Jira. Org-wide agent inventories, separated permissions for AI access versus agent building, dashboards for credit consumption — the whole compliance picture got serious.

This is the answer to the “shadow AI” problem that has had every CISO I know writing nervous Slack messages for a year. You can give your organization broad agent capability without losing the audit trail. That changes the political math on agent rollouts. The conversation moves from “can we even let people use this” to “here is the controlled program we're going to run.”

Rovo Studio, Max, and the democratization push

The general availability of Rovo Studio deserves more attention than it got under the keynote rush. It's a single workspace where any team — not just engineers and platform power users — can turn an idea into an agent, an automation, or a small app, in natural language, with governance baked in. Combined with Max, the new reasoning mode in Rovo Chat that breaks down messy multi-step asks and runs them end to end, you have a credible path for non-technical teams to build real working AI capabilities without filing six tickets and waiting six months.

The historical pattern is that platforms which democratize building also quietly increase the cleanup work for the central team. That's the part to plan for now, not later. The companies that win this phase will pair Rovo Studio access with a clear “agent of record” pattern — named owners, sunset dates, and a quarterly review of what's still earning its keep.

Confluence learned to remix, and Loom learned to brief

A small but delightful set of updates that compound over time. Remix with Rovo in Confluence (beta) reshapes prose, tables, and lists into infographics, charts, databases, and timelines without leaving the page. Confluence Slides is coming, which keeps a single source of truth across page and presentation. Create with Rovo in Jira closes the loop the other direction — turning Confluence docs and meeting summaries into structured Jira work items, with teams reportedly starting work up to 30% faster.

The Loom side of the house got a quieter but very clever update too: agent briefings in Loom let you record a walkthrough showing exactly what you mean, and the recording becomes structured multimodal input an agent can act on. If your team has ever burned twenty minutes trying to describe a UI bug in Slack, that one will earn its keep within a week.

None of these are flashy. All of them remove friction from the daily knowledge-work loop. The compounding effect across a year is significant.

What I'd actually do this week

If you're a leader trying to translate three days of announcements into a real plan, here's the partner-honest short list.

• Inventory your Teamwork Graph. Not the apps you have — the connections you have. Where is institutional memory living, where is it leaking, and which connections do you wish your AI tools could already reason over? That assessment is the highest-leverage exercise you can run before any agent strategy.
• Stand up your agent governance program now. Not after someone in marketing wires up an unsupervised agent that emails a Fortune 500 customer at 2 a.m. The controls Atlassian shipped this week make this a real program, not a policy document.
• Adopt a continuous-update posture. Pick one person whose job description includes “reads release notes weekly and translates the relevant ones into action.” If that's nobody on your team, that's the gap a partner like ours fills.
• Pilot one Rovo Studio use case outside engineering. Marketing, HR, finance, support — pick the function with a tedious repeating workflow and let them build something that visibly removes pain. Internal credibility for the AI program lives or dies on that first non-engineering win.

The Avaratak Take

A small honest word from the trusted-advisor seat. The thing I keep coming back to is that this is not a year where the right strategy is to wait and see. Atlassian made an architectural commitment this week that reshapes what their stack means to a customer. The companies that build their context layer early — and instrument the governance, training, and rollout discipline to scale agents responsibly on top of it — will pull noticeably ahead of the ones that treat AI as a side project.

That isn't hype. It's just what we're already seeing in the engagements running ahead of the curve right now.

If your team came back from Anaheim with a notebook full of ideas and the dawning realization that turning them into a sequenced plan is going to be a full-time job, that's the conversation we have for a living at Avaratak Consulting. As an Atlassian Solution Partner, our job is to take announcement waves like Team '26 and convert them into the smallest set of right moves, in the right order, for your real environment. Drop us a line at avaratak.com. The agents will wait. Your context, you build now.

Mike Cannon-Brookes opened the Founder Keynote in Anaheim this morning with a line worth stealing for your next leadership offsite: “In 2026, anyone can buy ‘smarts’ by the token.”

It's a tidy way of saying that the AI race is no longer about who has the cleverest model. Frontier models are commodities. The advantage belongs to organizations that can hand AI agents real context — what your team is working on, why you decided what you decided, who owns what, and what good looks like — and then trust those agents to act on it.

That one idea ran through every announcement at Team '26 today. And there were a lot of them. Here's the trusted-advisor tour, organized so you can decide what actually matters for your environment.

The Teamwork Graph just got a front door

The headline announcement isn't a feature. It's a posture change. Atlassian opened the Teamwork Graph — the underlying map of how work, decisions, code, people, and tools connect across your stack — to outside agents and tools through two new open-beta interfaces:

• A Teamwork Graph CLI with more than 300 commands, so coding agents like Claude Code and Cursor can query work and relationships across Atlassian through one consistent surface.
• Teamwork Graph tools via the Rovo MCP Server, extending what the MCP Server has already been doing for Claude, Cursor, and Gemini CLI users.

For scale: the Graph now contains more than 150 billion connections, with 12 billion changes flowing through it every day. Translation: this is the layer that makes any agent — first-party or otherwise — actually useful, because it already knows which decisions, tickets, and documents exist.

Rovo grew up

Three announcements you'll feel inside a quarter:

1. Rovo Studio is now generally available — one workspace where anyone (not just developers) can design agents, automations, and apps in natural language, with governance baked in. This replaces the patchwork of “where do I build this thing?” most teams have been wrestling with.
2. Max mode in Rovo Chat (coming soon) is a new reasoning mode for messy, multi-step work. Hand it a complex ask and it builds an action plan, coordinates across Atlassian and connected SaaS apps, and corrects itself along the way.
3. Code Intelligence in Rovo (early access) lets engineers and agents ask intent-level questions across multi-repo environments — “which services still use the old auth pattern and who owns the migration?” — instead of grepping for strings.

In the last month alone, customers performed more than 14 million Rovo-assisted actions, and agentic automations are up 7x in six months. This isn't theoretical adoption.

Agents in Jira hit GA

Agents in Jira moved from open beta to generally available today. You can assign Jira work items to Rovo agents and to third-party agents from Amplitude, Canva, Cursor, Figma, Gamma, GitHub Copilot, and more. Every interaction is auditable, traceable, and governed. Comments work. Mentions work. Workflow status changes can trigger agent ownership automatically.

That last detail matters. It means agents don't live in a sidebar pinned to your screen. They live in your board, in your queue, in the same place humans plan and track work.

Confluence learned to remix

Three Confluence updates worth flagging:

• Remix with Rovo (beta) lets you select any block of text, table, or list on a page and reshape it into a chart, infographic, timeline, geo map, quadrant, or flip card without leaving the page.
• Confluence Slides (coming soon, beta) extends Remix to slide decks, so the same source content can stay synced across page and presentation. One source of truth, two formats.
• Create with Rovo in Jira (beta) closes the loop the other direction — turn Confluence docs, meeting summaries, and email threads into structured Jira work items. Atlassian says teams using it start work up to 30% faster.

Loom learned to brief agents

Agent briefings in Loom (beta) is one of the most underrated announcements of the day. Instead of typing a long prompt, record a Loom showing exactly what you mean — walkthrough, designs, feedback, the works. The recording becomes structured multimodal input an agent can act on. If your team has ever lost twenty minutes trying to describe a UI bug in Slack, this one's for you.

DX gives AI a P&L

The DX AI Experience is now generally available. With Agent Experience, AI Code Insights, and AI Pulse, engineering leaders can see where AI is actually generating code, how agents are performing, and what the ROI looks like. AI moves from black box to measurable part of the software development lifecycle. For anyone whose CFO has started asking pointed questions about AI spend, this is the answer sheet.

New collections and products

A quick rundown of the rest:

• Product Collection (early access) — Jira Product Discovery, the new Feedback app, and a planned Pendo integration, so product teams go from signal to shipped without bouncing between tools.
• Jira Product Discovery Enterprise — generally available, with portfolio-level governance.
• Incident Command Center — unifies incident detection, investigation, and resolution, with Rovo-assisted root-cause analysis.
• Dia Reports — proactive browser-native briefings (interview prep, decision memos, the kind of doc you usually scramble to assemble at 11 PM the night before) generated from Teamwork Graph context. The headline trick: Dia surfaces reports before you ask for them.

Governance got teeth

Every announcement above is wrapped in upgraded controls:

• Org-wide agent lists and insights so admins have a live inventory of who built what, where it's running, and how often it's used.
• Separated permissions for AI access vs agent building — so you can give the org broad usage without authorizing everyone to spawn new agents.
• Tightened policies for what third-party data Rovo can ingest, plus controls for data residency and Atlassian-hosted LLM selection.
• Dashboards and audit logs for AI adoption and credit consumption.

This is the part that lets enterprise security teams sleep at night. It's also the part most “AI for the enterprise” pitches skip entirely.

The pricing posture

Cannon-Brookes signaled the model is staying hybrid: seat-based core products with generous allowances for Rovo credits, indexed objects, and Forge usage, plus usage-based tiers for heavy consumers. The intent is that most customers live inside the envelope and only the unusual edge cases (his example: thousands of agents inside a five-person company) hit the metered tier.

The cadence shift

Buried in the keynote but arguably the most important strategic note: Atlassian is moving away from saving up big launches for twice-yearly events. They're explicitly committing to ship in public, every day, alongside customers. Today's announcement wave is large. The cadence going forward will be smaller and continuous.

For Atlassian admins, that means staying close to release notes is the new minimum. For Avaratak customers, it means we'll be earning our keep — picking signal out of the stream and translating it into “here's what to actually do this week.”

What this means for your shop

A few takeaways while the dust settles:

• If you've been waiting for agents in Jira to be production-ready, today is the day. GA plus governance plus third-party agent support means you can pilot without a security-review marathon.
• The Teamwork Graph opening up is a partner-and-customer story as much as it is an Atlassian story. The richer your Graph, the smarter every agent — first-party or third-party — becomes.
• Rovo Studio plus the agent governance controls finally answer the “shadow AI” question for enterprise IT. You can give the org access to build without losing the audit trail.
• DX AI Experience is the missing piece for anyone who needed to defend their AI spend with a number, not a vibe.

As an Atlassian Solution Partner, Avaratak Consulting helps teams turn announcement waves like this one into actual outcomes — picking the right pieces, sequencing the rollout, training the humans, and making sure the agents end up doing what you actually want them to do. If today's news raised more questions than answers, that's exactly the conversation we have for a living. Drop us a line at avaratak.com.

I just got off a 6 a.m. red-eye, walked into the Anaheim Convention Center, and stood in line for a coffee. That's where I learned everything I needed to know about Team '26.

The Solution Partner ahead of me was telling a customer she'd just met, “We rolled out Rovo agents to their service desk in February and the deflection rate is up 38%.” The customer, who had until that moment been politely sipping a flat white, set the cup down and pulled out her phone to take a note.

That's the moment, multiplied by about 5,000 across the convention floor today, that explains why this is going to be a Team conference people remember.

Day 1 of Team '26 is technically a soft day — the founder's keynote and the big product announcements happen tomorrow morning. The official Tuesday agenda is preconference workshops, registration, the Atlassian Hub demo center, and the opening keynote at 5:30 p.m. on the Main Stage. On paper, it's a warm-up.

In the hallways, it is anything but.

What “Day 1” Actually Looks Like

If you've never been to a Team event in person, here's the rhythm. The official program starts in the early afternoon. The actual conference starts at 7 a.m. when the Build IT Together preconference kicks off at the Clarion Hotel a few minutes from the main expo. Strategy Collection is running back-to-back workshops on Focus, Talent, and Align in room 304A — both the 12:30 and 4:00 sessions were full by Friday. The Atlassian Hub doors opened at 3 p.m. with the Strategy Collection booth three deep within thirty minutes.

The customers who've been to a few of these don't show up at 5:30 for the keynote. They show up at 9 a.m. and get the entire pre-show conversation that the agenda doesn't put on paper.

That conversation, this year, has a very specific texture.

The Conversation Has Shifted

Two years ago at Team '24 in Las Vegas, the dominant hallway question was, “How do I get started with Rovo?” Last year at Team '25 here in Anaheim, it was, “Which Rovo agents are actually worth the configuration time?”

This year, twelve hours in, I've heard the question reframed three different ways from three different customers, all of them landing in the same place: “I have AI agents shipping real outcomes in production. How do I scale the program?”

That's a completely different conversation than the 2024 version. It's the conversation companies have after they've stopped asking whether AI works and started asking how to govern, measure, and expand the wins. The Atlassian ecosystem has been in unusually fast company on this curve, and Day 1 has the distinct feel of a community that knows it.

The Teamwork Graph storyline, which felt aspirational at Team '25, now feels like infrastructure. The Strategy Collection, which launched in October 2025, has matured into something customers are describing in their Day-1 elevator pitches the way they used to describe their Jira instance. The Rovo agent ecosystem has expanded enough that I overheard a CIO ask his architect, “Have we tried the new one for incident summarization yet?” — a sentence that would not have made grammatical sense at Team '24.

The View From the Solution Partner Side

I'll be honest about the partner experience because it's worth saying out loud.

The Atlassian Solution Partner ecosystem at Team conferences has always been collaborative. Competitive, but collaborative. We genuinely root for each other to make customers successful, because the alternative — fragmented service quality — hurts the entire ecosystem. That energy is louder than ever this year, and I think it's because the work has gotten bigger.

A typical Avaratak engagement two years ago was a Jira workflow redesign or a Confluence migration. A typical Avaratak engagement today involves Rovo agent design, Teamwork Graph integration patterns, Strategy Collection rollouts that connect goals to delivery, and the kind of change-management conversation that has nothing to do with technology and everything to do with how a real company actually decides things. The complexity is up. The stakes are up. And the partners I've talked to today — the ones who are doing the work well — are sharper, more intentional, and more openly collaborative than I've ever seen them.

That's the version of the ecosystem you want to be a customer of.

What I'm Watching For Tomorrow

Without speculating on specifics — because I'm not in the keynote rehearsals and I respect Atlassian's right to surprise us — here's what I'll be paying attention to during Wednesday morning's founder's keynote.

The agent ecosystem story. Atlassian has been unusually clear that the future is not “one big AI” but “a curated set of specialized agents working alongside humans.” I expect that story to get a meaningful push tomorrow, with concrete new capabilities for both customers and partners.

The strategy-to-delivery story. The Strategy Collection launched seven months ago. Tomorrow is the moment to find out how it's connecting to the Teamwork Collection, the Service Collection, and Jira Align in ways that finally retire the “fragmented operating model” diagnosis Atlassian has been making for two years.

The Forge and Marketplace story. Atlas Camp Amsterdam in March previewed Forge-hosted LLMs and Forge Container Service. If those land tomorrow as GA-ready, the partner build community is going to have a very loud, very happy afternoon.

I'll be writing about all of it as soon as the dust settles.

The Avaratak Take

A small honest word from the trusted-advisor seat.

The reason we make the trip to Team every year — even when the calendar says we're slammed, even when the timing is inconvenient — is that the value of being in the hallways is not really about the announcements. It's about the conversations the announcements set off. It's the customer who pulls you aside at the coffee station and tells you about the workflow they're stuck on. It's the partner who shares a hard-won lesson from a rollout they did last quarter. It's the Atlassian product manager who answers a question candidly because you happened to be standing next to her in the line for the bathroom.

Those conversations are the actual product of a Team conference. The keynote is the highlight reel. The hallway is the substance.

If your team is at Team '26 this week and you'd like to grab a coffee, find me — I'll be in the partner zone, in the Strategy Collection booth, or somewhere with a cinnamon roll trying to pretend the time-zone change isn't real. Or stop by avaratak.com and drop us a note. We're always happy to talk through what the announcements actually mean for a real team trying to get real work done.

A coffee-line conversation on Day 1 of Team '26 is the highest-leverage thirty minutes you'll spend in 2026. See you in the hallway.

I want to tell you about a small Bitbucket Pipelines update that quietly solves a problem I've been hearing about from build engineers for the better part of a year.

Last fall, one of our DevOps clients sat me down to walk me through what he called "the workaround tour." His team had recently restructured their CI/CD into parent and child pipelines — modular, reusable, beautifully separated by concern. Build pipeline up top, test pipelines hanging below, deployment pipelines after that. Textbook architecture. Until you needed to actually pass something between them.

"So I just upload to S3 between every step," he said, gesturing at a diagram with three arrows labeled "S3" pointing in suspiciously identical directions. "And then I download it on the other side."

He wasn't proud of it. Nobody is when their CI/CD architecture has a side gig in object storage. But until very recently, that was the cleanest way to share a build artifact between a parent pipeline and the child pipeline it had triggered. A whole layer of duct tape that existed only because the feature underneath wasn't quite finished.

That layer just got retired. Atlassian announced that Bitbucket Pipelines now lets you share artifacts directly between parent and child pipelines — and as someone who spends a meaningful portion of every week elbow-deep in client CI/CD configurations, I want to walk you through why this seemingly small release is actually a quietly significant turning point.

The Family Tree, Briefly

For anyone who hasn't waded into parent/child pipelines yet, here's the short version. Bitbucket Pipelines lets you define a step in a pipeline that doesn't run a script — instead, it triggers an entire other pipeline. The triggering pipeline is the parent. The triggered pipeline is the child. The architecture lets you break complex CI/CD logic into modular pieces that can run in parallel, get reused across projects, and stop turning your YAML into the kind of file people apologize for before opening.

It's a beautiful pattern. And like most beautiful patterns, it had a sharp edge: parents and children couldn't share files. The parent could build a JAR, but the child running tests against that JAR had to fetch it from somewhere else. The child could produce a coverage report, but the parent couldn't read it back. So teams improvised. They used external storage. They restructured their pipelines to avoid the handoff. They lived with redundant build steps. They Slack-messaged each other about it sometimes.

Atlassian closed the gap. You can now declare an artifacts block on a child-pipeline step that lists what gets uploaded into the child and what gets downloaded back from it. Files flow both directions. The whole "I'll just put it in S3" workaround has been quietly demoted to "remember when we had to do that?"

What Actually Changed

The mechanics are refreshingly simple. In your YAML, the step that triggers a child pipeline now accepts an artifacts section with two lists: upload and download. Anything in upload is the last version produced by the parent before the child step — that file becomes available for download in every step of the child pipeline. Anything in download is the last version produced by the child — it becomes available in every step of the parent that runs after the child step finishes.

The Atlassian docs use a charming "message in a bottle" analogy in their example. Parent step writes a message into bottle.log. Parent calls child pipeline with the bottle in the upload list and the download list. Child reads the message, scribbles a postscript, sends it back. Parent step downstream reads the final note. It's a goofy example that disguises a real architectural unlock.

There's a sensible cap — twenty upload artifacts and twenty download artifacts per child pipeline step — which is generous enough that I haven't seen a real-world workflow bump into it. It pairs cleanly with the variable-sharing feature Atlassian shipped a few months earlier, which lets parents pass typed input variables down to their children. Together, those two features make the parent/child pipeline pattern feel like a genuinely first-class abstraction instead of a clever-but-isolated trick.

Why This Matters More Than the Release Notes Suggest

A few patterns suddenly become much cleaner.

Build once, test in parallel children. Your parent compiles the artifact. Three child pipelines, running in parallel, each pull that exact artifact down and run a different test suite — unit, integration, end-to-end — against it. No rebuild. No cache invalidation puzzle. No wasted compute. Build minutes go down. Confidence in the artifact-under-test goes up.

Let children produce, parents publish. The mirror version. Child pipelines generate coverage reports, security scans, or dependency audits. The parent gathers them up, attaches them to the merge request, and decides whether to proceed with deploy. The child stays focused on producing one clean output. The parent stays focused on coordinating. Nobody is reaching across pipeline boundaries through external storage just to pass a JSON file.

Reusable child pipelines that take real inputs and produce real outputs. This is the one I'm most excited about. With variables flowing in and artifacts flowing both directions, a child pipeline starts to look exactly like a function call — typed inputs, typed outputs, encapsulated logic. Teams can finally build a library of reusable child pipelines (a "scan this image" pipeline, a "lint this language" pipeline, a "deploy to this environment" pipeline) that get composed across dozens of projects without each project reinventing the wiring.

That last pattern is the one that quietly changes how mature engineering organizations build CI/CD. It's the difference between every team writing their own pipeline from scratch and every team consuming a curated library of vetted, secure, observable pipeline modules. The blast radius of "we updated the security scan" goes from "every team please update your YAML" to "we updated the central pipeline; you'll get the new behavior on your next run."

The Avaratak Take

A few honest words from the trusted-advisor seat.

Audit your S3 workarounds. If your CI/CD has cloud storage in the loop only because parent/child pipelines couldn't share files, that's a refactor worth scheduling. Removing it cuts complexity, removes a whole class of credential management problem, and usually shaves real money off your build infrastructure bill.

Treat child pipelines like reusable modules. Now that they accept variables in and artifacts out, design them with that contract in mind. Name your inputs. Name your outputs. Document the contract in a README in the same repo. The teams that lean into this end up with internal pipeline libraries that look more like SDKs than scripts.

Pair this with the new artifact types. Atlassian shipped shared and scoped artifact types alongside selective download last fall. Use shared for the artifacts you're passing between parent and child. Use scoped for the per-step logs and screenshots you don't need to ship downstream. The combination keeps your pipeline storage tidy and your steps fast.

Don't over-engineer day one. The first project we ever migrated to parent/child pipelines went too far, too fast, and ended up with a tree of pipelines harder to read than the monolith we'd replaced. The right move is to extract one or two clearly reusable patterns first, validate them on real workloads, and let the abstraction earn its way deeper into your CI/CD architecture.

Worth Saying Out Loud

There's a particular kind of joy that comes from watching a tool retire one of your workarounds. Every team has a list of duct-tape solutions they've stopped noticing — bits of clever scaffolding that exist only because the platform underneath wasn't quite finished. When the platform catches up and the workaround can be deleted, the team gets back not just the maintenance overhead but a small piece of clarity. The mental model shrinks. The architecture gets honest.

That's what this update is. Not a flashy feature with a launch event. A quiet, useful closing of a gap that build engineers have been working around for a while. The kind of release that pays compounding dividends inside teams that actually use Bitbucket Pipelines as a serious part of their delivery infrastructure.

If you're running parent/child pipelines today and your S3 bucket has a "pipeline-handoffs" folder, this is exactly the conversation we love at Avaratak Consulting. Stop by avaratak.com and bring your messiest pipeline. We'll bring the refactor plan. Together we'll figure out which of your workarounds can finally retire to the part of the YAML where they belong — the git history.

Let me tell you about a Tuesday that changed how I think about HR.

I was sitting with the head of People at a 200-person tech company, and she was showing me her onboarding spreadsheet. Color-coded. 47 columns. Eight tabs. A legend on the side that explained what "yellow with a star" meant versus "yellow with a strikethrough." She said, with the kind of tired pride that only comes from years of holding chaos together with willpower, "This is how every new hire gets onboarded. It works. Most of the time."

I asked her what happened on the days it didn't work. She got quiet. Then she listed them: laptops that arrived three days after start dates, badges that didn't open the right doors, payroll setups that got missed because someone was on PTO when the email came in, new hires sitting in lobbies wondering if they had the wrong building. Each one a small failure. Each one a story the new employee would tell about their first impression of the company.

That spreadsheet was working. And it was also, very quietly, costing the company every single hire.

I'm telling you this because the conversation that followed is the same one I've now had with HR leaders across dozens of companies. And the punchline is always the same: HR is one of the most underserved functions inside Jira Service Management, and it shouldn't be. JSM was practically built for what HR is actually trying to do.

Why HR and JSM Belong Together

Here's the framing I give every HR leader I work with.

Your job, at its core, is service delivery. Every onboarding is a service request. Every benefits question is a ticket. Every offboarding is a coordinated workflow across multiple teams. Every leave-of-absence has approvals, status updates, and SLAs that real human beings care deeply about. The mental model you've been told to use — spreadsheets, email threads, the occasional shared form — is dramatically underpowered for the work you're actually doing.

JSM was designed for service delivery. Request portals. SLAs. Approvals. Knowledge bases. Cross-team coordination. The exact muscles HR has been forced to grow inside Outlook for the last fifteen years. And the kicker: most companies already own JSM because IT is using it. The license, the platform, the integrations, the admin team — it's all sitting there, waiting for HR to walk in and use it.

The version of JSM in your head is probably smaller than the one waiting for you.

Six Ways HR Teams Are Putting JSM to Work

Let me get specific.

Onboarding orchestration. The headliner. A hiring manager submits one request — "new hire starting March 15, software engineer, San Francisco office" — and JSM cascades the work to IT (laptop, accounts, software), Facilities (desk, badge, parking), Payroll (system setup, direct deposit), and HR itself (paperwork, orientation scheduling). Each team gets the right subtask in their own queue with their own SLA. The new hire's manager sees a single dashboard of progress instead of forwarded emails. The HR team's role shifts from "coordinator-of-last-resort" to "orchestrator with visibility." When Atlassian rolled out Journeys for JSM, this exact use case is what they built it for.

Employee help desk. The catch-all. Benefits enrollment questions, payroll discrepancies, policy clarifications, "how do I update my direct deposit" — all of it lives in a clean self-service portal instead of buried in your inbox. Pair it with Confluence as the knowledge base behind the scenes, and roughly 30 to 40 percent of routine questions get deflected before they ever land on an HR pro's plate. That's not a hypothetical number. That's the average we see at clients within 90 days of going live.

Leave and absence requests. A request type with the right form fields, the right approval chain, and an automatic notification to payroll when approved. The employee gets a tracked confirmation. The manager gets a clean approval flow. HR gets an audit trail. No one is digging through a Slack thread three weeks later trying to remember what was approved.

Offboarding. The mirror image of onboarding, and arguably the higher-stakes one because security and compliance are watching. JSM coordinates account deactivation, asset return, exit interview scheduling, final pay calculations, and benefits notifications across the same teams that did the onboarding. One ticket. One audit trail. One reduced risk of the ex-employee still having Slack access two weeks later.

Internal mobility and role changes. The forgotten use case. When someone changes teams or gets promoted, there's a mini-onboarding hiding inside the change — new system access, new manager, sometimes new equipment, often new training. Most companies handle this with email and crossed fingers. JSM handles it with the same workflow muscle as net-new hires, just with different subtask templates.

Sensitive case management. The one I always recommend last because it requires real care. Investigations, accommodations, complaints — these are the cases that absolutely cannot live in shared inboxes or forwarded emails. JSM's permission model lets you create a separate, restricted-access request type where only the relevant HR business partners can see the case. Audit trail intact. Privacy preserved. Compliance happy.

What Makes the Difference Between "Tool" and "Transformation"

Two practical observations from years of doing this work.

The portal experience is the make-or-break. If your HR portal looks like a generic IT ticket form, employees will treat it like one — with the same tepid enthusiasm they reserve for filing expense reports. If it looks like a thoughtful, on-brand experience that respects what the employee is actually trying to do, they will use it eagerly. The investment is small. The behavioral shift is enormous. Custom request types, smart forms with conditional logic, and a knowledge-base sidebar make the portal feel like a service — because it is one.

Automation is your competitive advantage. Atlassian's own data shows that 65% of managerial tasks can be automated, and HR is sitting on a goldmine of repetitive coordination that JSM's automation engine handles in its sleep. Auto-routing requests to the right HRBP based on the employee's department. Auto-creating Confluence pages for new hire welcome packets. Auto-syncing with your HRIS so a new record in Workday triggers an onboarding journey in JSM. The teams that lean into this go from "firefighters" to "experience designers" within a couple of quarters.

Where Avaratak Comes In

An honest word from the trusted-advisor seat.

HR-on-JSM rollouts succeed or fail based almost entirely on the planning conversation that happens before anyone touches a configuration screen. The technical work is the easy part. The real work is mapping your actual employee experience — every touchpoint, every cross-team dependency, every "oh and we also have to remember to…" exception — and translating it into request types, workflows, and SLAs that respect how your company actually operates.

That's what we do at Avaratak Consulting. We've helped HR teams of every size go from spreadsheet-and-willpower to a service-grade employee experience inside JSM, and the results consistently land in the same neighborhood: 50 to 70 percent reduction in coordination time per hire, 30 to 40 percent ticket deflection through self-service, and the kind of audit trail that makes your compliance team smile at you in the elevator instead of catching your eye and looking away.

Three practical recommendations.

Start with onboarding, not everything. Onboarding is the highest-stakes, highest-visibility, most-broken HR workflow at almost every company. Win it first. The credibility you build there opens every other conversation.

Connect to your HRIS. Workday, BambooHR, Rippling — whichever one you use, JSM can sync. The moment a new employee record is created in your HRIS, the JSM journey can fire automatically. No more "did anyone hear we have a new hire next Monday?"

Treat the portal like a product. Your employees will use it dozens of times over their tenure. Invest in making it feel intentional. Customize the language. Add the right knowledge articles. Test the forms with real employees before you launch.

Worth Saying Out Loud

HR is some of the most consequential work happening inside any company. The stories your employees tell about how they were welcomed, supported, and respected become the stories your company is known for. Tools that make that work easier, more visible, and more consistent aren't a nice-to-have — they're a strategic asset.

Jira Service Management is one of the best-kept secrets in the HR-tech conversation, and it's hiding in plain sight inside companies that already own it. If your HR team is still running the spreadsheet-with-47-columns playbook, that's exactly the conversation we love at Avaratak Consulting. Stop by avaratak.com and bring your hardest onboarding story. Odds are very good there's a JSM workflow waiting to retire it.

I want to start with a number that genuinely surprised me when I first read it.

When tech teams started using Loom inside their Jira Service Management workflows, triage time dropped 30 to 50 percent. Not 5. Not 10. Thirty to fifty. The kind of number that makes you reread the post to make sure you didn't hallucinate it.

Then I sat with it for a few minutes and thought: of course it does.

Because the bottleneck in most service desks isn't actually fixing the problem. It's understanding the problem well enough to start.

Every help desk veteran has lived this loop. The ticket comes in: "the thing isn't working." Three back-and-forth comments later, you're still trying to figure out which thing, on which screen, with what error message. Meanwhile the customer is getting frustrated. The agent is getting frustrated. And the actual fix probably would have taken 10 minutes if anyone could have just seen what was happening.

Loom inside JSM eliminates that loop. And that's only the beginning of why this combo deserves real attention from anyone running a service desk in 2026.

What's Actually Different Now

Atlassian acquired Loom in 2023, and at the time, a lot of people read it as "okay, so Atlassian wants a video tool now." Two years later, the picture is much clearer. Loom isn't a bolted-on feature. It's the missing communication layer JSM was always quietly crying out for.

The most consequential update is Loom's enhanced bug reporting mode, which automatically captures everything an engineer needs to start investigating:

Browser and device info. No more "can you tell me what version of Chrome you're on?"

Network logs. Failed API calls, payloads, headers, slow requests — all attached.

Console errors and warnings. The errors developers actually need are right there, timestamped to the exact moment of the user's recording.

When that data lands in a JSM ticket alongside a 90-second video showing exactly what the user did, the conversation changes. There's no "can you check your dev tools?" There's no "did you reproduce it in incognito?" The ticket arrives ready to investigate.

Five Ways This Lands in a Real Service Desk

1. Customer-reported issues with rich technical context. Customers struggle to describe technical problems in writing, but they can show one. With the Loom Chrome extension installed, a user can record a 60-second video reproducing the issue, and Loom AI auto-generates a JSM ticket with the video embedded, the steps written out, and the technical metadata attached. Three rounds of email become one Loom.

2. Internal IT support requests that don't require a meeting. Your CFO has a question about why their VPN keeps dropping. Old way: schedule a 20-minute screenshare to debug it. New way: CFO records a 2-minute Loom showing what they see, the IT team watches it on their schedule, sends back a 1-minute Loom with the fix. Total elapsed time: maybe 30 minutes. Total meetings: zero.

3. Incident response with auto-captured post-mortems. The Loom Meeting Assistant can join your post-incident reviews, transcribe the conversation, and surface decisions and action items into a JSM-linked Confluence page. The post-mortem template that used to require a designated note-taker writes itself. Engineers stay in the conversation, not in a notes app.

4. Knowledge base articles that don't go stale. Service desk teams typically have a Confluence knowledge base linked to JSM. The trouble? Written KB articles drift out of date the moment a UI changes. A 90-second Loom showing how to do something stays accurate as long as the screen looks the same — and you can re-record it in the time it takes to write a paragraph.

5. Cross-timezone handoffs that don't require living in Slack. Your London team finds a tricky issue. They record a Loom, attach it to the JSM ticket, log off. Your San Francisco team comes online four hours later, watches the 3-minute video, picks up exactly where London left off. No meeting. No "can we hop on a call." Just continuous, async progress.

The Numbers

Atlassian publishes some honest customer data on what changes when teams adopt this workflow.

30 to 50% reduction in triage time for support requests with Loom-attached technical context.

3 to 5 hours of meetings eliminated per developer per week when Loom replaces "quick clarification" calls.

25 to 30% overall reduction in meeting volume once async video becomes the team default.

I cite vendor numbers carefully — every vendor has hopeful research. These line up with what I've watched happen with my own clients. The before/after on time-to-first-response and time-to-resolution is genuinely visible within a couple of months.

The Avaratak Take

Tools like Loom + JSM compound when teams adopt them genuinely, and they stall when teams adopt them halfway. A few practical recommendations.

Make Loom recording dead simple to start. Install the Chrome extension on every service desk agent's machine. Make sure the JSM portal has a clear "record a video" path for customers and employees submitting requests. Friction kills adoption — eliminate it on day one.

Standardize what a "good Loom" looks like. Train your service team to record short, focused, narrated walkthroughs. Show, don't ramble. The 90-second Loom that surfaces an issue clearly is worth a hundred 8-minute recordings that bury the lead. Set norms early.

Connect Loom + Confluence + JSM as one knowledge graph. The full power isn't Loom alone — it's Loom feeding Confluence (for reusable knowledge), Confluence feeding JSM (for self-service deflection), and JSM feeding Confluence again (for new articles when novel issues get resolved). Treat it as a system, not a tool.

Plan for the AI workflows. The Loom AI features that auto-create Jira tickets, write meeting summaries, and suggest work item updates are the real multipliers. Make sure your team is on a Loom Business + AI or Enterprise plan if you want the full benefit. Your procurement team will thank you for budgeting this once instead of three times.

The Bigger Picture

Service desks have always been bottlenecked by communication. Not because agents are slow, but because text-based tickets force everyone — customers, agents, engineers — to translate visual reality into written description and back again. Every translation step costs time and accuracy.

Loom + JSM removes the translation. Visual reality goes straight from the user's screen to the agent's queue, complete with technical metadata an engineer can act on without asking three follow-up questions.

That's not a feature. That's a structural improvement to how service work flows.

If you're running a service desk and you haven't seriously evaluated this combination yet, my honest advice is don't wait another quarter. The teams that integrate Loom into their JSM workflows now will compound advantages on triage time, customer satisfaction, and after-hours coverage that the teams still asking "can you reproduce that?" are going to find very hard to catch up to.

That's exactly the kind of conversation we love at Avaratak Consulting. If you'd like a partner to help you wire Loom + JSM into a service experience that actually feels like it was designed in 2026, stop by avaratak.com. We'll bring the playbook. You bring the tickets that have been driving your team a little bit crazy.

I was scrolling through the Atlassian community page yesterday morning, coffee in hand, and stopped on a post timestamped "18 hours ago." That's not a typo. The Jira 2026 Spring Release dropped while most of us were sleeping, and by the time I'd finished my first cup, I had already texted three clients with some version of the same message: okay, this one's actually a big deal.

Let me explain why.

The Headline Most People Are Going to Miss

For the past two years, the conversation about AI in Jira has mostly sounded like "how do we use AI to fill in summaries faster?" Useful, but small. The 2026 Spring Release is the moment Atlassian formally pivots that conversation. The new headline isn't "AI helps you fill out tickets." It's AI agents are now teammates inside Jira.

You can now assign work to a Rovo agent the same way you'd assign it to your engineer named Maria. You can @mention an agent in a comment thread and have it iterate with you in context. You can embed agents directly into workflow steps so they design, execute, and update work alongside humans — with the same project configurations, permissions, audit trails, and approval flows that govern every other contributor.

That's not a feature. That's a paradigm shift, and it's shipping to general availability for all Jira Cloud customers by early May 2026.

What Actually Changes

A few specific updates jumped out at me as the ones that will land hardest in real customer environments.

Agents in Jira (open beta). Three things to know. One: it's not just Atlassian's own Rovo agents — third-party MCP-enabled agents work too, which means the ecosystem you've already invested in keeps working. Two: agents respect your existing Jira governance. They don't bypass permissions. They don't punch holes in your audit trail. Three: agents in Jira are designed to be assigned, not summoned. The mental model shifts from "open AI tool, paste context, copy result back" to "add the work item to the agent's queue."

Rovo Dev now lives inside Jira work items. The earlier release that put Rovo Dev into VS Code was useful. Putting it directly into a Jira work item closes a loop that's been broken for as long as I've been advising clients. Open the ticket, click "Generate code," point Rovo Dev at your repository, and it pulls context from the issue, your codebase, and Confluence to produce working code in a secure cloud sandbox. Approve. Open the PR. Done. The bridge from "requirement written" to "merge-ready PR" just got dramatically shorter — and it can be wired into Jira Automation rules to multiply across recurring work.

Rovo cross-tool search inside Jira. The native Jira search has always been competent. The new Rovo-powered search makes it actually conversational. "Show me open design tickets blocking engineering" is now a thing you can ask in plain English. Anyone who has tried to teach a colleague JQL knows how big a quality-of-life upgrade this is.

The new workflow editor becomes the default. The legacy editor is still accessible, but it's heading for sunset in June 2026. If you've been putting off familiarizing your admin team with the new editor, this is your nudge. The new one is genuinely better — cleaner, more intuitive, easier to teach — but the change-management work is still real.

Jira Plans gets richer custom field support. Program managers, this one's for you. Plans (formerly Advanced Roadmaps) now lets you view, filter, sort, and add a much wider range of custom field types directly on the timeline. The data you've been building elaborate workarounds to surface? It just works in the planning view now.

A cleaner attention view. The new "single, cleaner view of what needs your attention" pulls assigned work, due dates, and relevant updates into one place. It sounds modest. It will save your team a meaningful number of meta-hours every week.

The Strategic Read

Here's what I'm telling clients this week.

The arrival of agents-in-Jira is the most consequential shift in how knowledge work gets organized since Jira itself displaced spreadsheets. For the next 18 months, the teams that thoughtfully integrate human and AI work inside the same shared system are going to compound advantages. The teams that keep AI in a separate browser tab — paste, copy, paste again — are going to fall behind in measurable ways.

That isn't hype. It's just the math of context-switching applied to a workforce that suddenly has an AI teammate per person. If the AI lives outside the system of record, every one of those AI conversations costs the team context. If the AI lives inside the system of record, every conversation deposits context for the next one.

Jira is positioning itself to be that system of record. The Spring Release is the formal announcement that the seat at the table has been set.

What Avaratak Is Telling Customers Right Now

Three practical recommendations.

Audit your Jira permissions and project structure before agents land at scale. Agents respect the rules you've set. If your rules are messy, the agents inherit the mess. Clean up project permissions, archive stale projects, and document who owns what. The teams that walk into the agent era with a tidy environment will get value on day one. The teams that don't will spend the first quarter untangling.

Pilot agents on a real, narrow workflow. Don't try to deploy agents across the org as a strategic initiative. Pick a single, well-understood workflow — a recurring intake form, a known refactor pattern, a triaging step for incoming requests — and let an agent run it end-to-end. The lessons from one focused pilot will save you months of broader rollout missteps.

Decide your data-collection posture before August 17, 2026. Atlassian's policy update on data contribution kicks in this summer. Lower-tier plans cannot opt out of metadata collection. Enterprise plans retain opt-out controls. If your industry has data governance requirements that make this consequential, the conversation about whether to migrate tiers — or to consider Atlassian Government Cloud or Isolated Cloud — needs to happen now, not in July. We've started this conversation with several clients already.

The Bigger Picture

The thing I want to leave you with is this. Jira used to be the place where work got tracked. The 2026 Spring Release is the moment Jira becomes the place where humans and AI work, together, inside the same shared structure. That's a meaningfully different product, and it's about to change how a lot of teams operate.

The teams that win the next 18 months won't be the ones with the flashiest AI demos in their all-hands meeting. They'll be the ones with the cleanest project hygiene, the clearest agent-governance practices, and a thoughtful sense of which workflows are right for AI and which ones still belong to human judgment.

That last part — the judgment about where AI fits and where it doesn't — is exactly the kind of trusted-advisor conversation we love at Avaratak Consulting. If you're staring at the Spring Release and wondering how to translate it into a 90-day plan that doesn't blow up your team, stop by avaratak.com and let's talk. We've spent enough years inside Jira instances of every shape and size to know which moves compound and which moves create cleanup work for next year.

I've been to a lot of tech conferences. I've collected the lanyards, eaten the rubbery breakfast burritos, and sat through the keynote that was secretly a 47-minute commercial for a product nobody asked for. So when I tell you that Atlassian Team '26 has earned a permanent spot on my calendar — and on the calendars of the clients I'm advising — that's not a polite endorsement. That's a strongly held belief backed by years of watching what comes out of Anaheim each spring and how quickly it changes the way teams actually work.

Team '26 lands at the Anaheim Convention Center on May 5–7, 2026. Yes, it's roughly a Lightning McQueen's distance from Disneyland. Yes, the meta-joke writes itself. But the real magic this year is happening inside the convention hall, and I want to walk you through what I'm watching for and why it matters for any team serious about how AI is reshaping work.

The Theme That Tells You Everything

Atlassian is calling Team '26 "the global conference for AI-forward teams, their leaders, and the apps and agents that fuel them." That isn't marketing fluff — that's a thesis statement. The company has spent the past two years methodically wiring AI into every layer of its platform, and Team '26 is where the puzzle pieces finally line up on the same table.

Mike Cannon-Brookes is opening the Wednesday keynote with a simple, slightly intimidating idea: human-AI teams, collaborating in one shared system of work, are about to become a company's biggest competitive advantage. I've been telling clients this for the better part of a year, often while gesturing with a coffee cup. Now they get to hear it from the source — with demos, customer stories, and a roadmap to back it up.

What I'm Genuinely Watching For

A few storylines are pulling me in harder than others.

The Strategy Collection getting some real teeth. Atlassian has been quietly turning Focus, Talent, and Align into the kind of strategic toolkit that connects scattered initiatives to actual outcomes. The session I'm most curious about is the live demo of Funds in Strategy Collection — the feature that links spend, benefits, and ROI directly to the work happening in Jira. If you've ever sat in a budget review trying to explain what your team actually delivered for the dollars allocated, this one should perk your ears right up.

Rovo growing up. Rovo crossed five million monthly active users earlier this year, and Team '26 is where the next chapter gets unveiled. I'm especially watching for deeper Rovo Studio capabilities, because the customers I'm advising have stopped asking "what can AI do for us?" and started asking "how do we build agents that fit our exact workflows?" That's a meaningful shift, and Atlassian is clearly leaning into it.

The cultural sessions. Adam Grant, the Wharton innovation expert, is on the agenda — and the pre-conference workshop block on AI teammates with specialized skills is, in my opinion, where the practical gold is. Most organizations don't stumble with AI because the technology lets them down. They stumble because the operating model doesn't catch up. The cultural and change-management sessions tend to be the ones I quote back to clients for months.

Three Days, Strategically Used

Here's how I'd think about the agenda if you're attending in person.

Day one is for orientation and big-picture energy. The Tuesday evening opening keynote sets the tone, and the Atlassian Hub is the place to wander, ask demo questions you'd be embarrassed to ask on a sales call, and meet the actual product managers shaping what you'll be using next year.

Day two is for product depth. The Wednesday keynote with Mike will frame the day, and the breakout tracks split cleanly between the Strategy, Service, Software, and Teamwork Collections. Pick the lane that aligns with your biggest initiative back home and resist the urge to bounce around. Depth beats variety here.

Day three is for the hallway track. I cannot overstate this — the Thursday sessions are excellent, but the conversations between sessions are where I've watched clients meet peers solving the exact problems they're solving, learn shortcuts no documentation has ever covered, and walk away with a phone full of new contacts who will save them weeks of trial and error over the next year.

Can't Make It to Anaheim? You Still Have a Seat

Team '26 streams live on May 6–7, with on-demand sessions opening May 11. MaSonya Scott and Sven Peters — both excellent and refreshingly human hosts — will be guiding the digital experience with behind-the-scenes interviews, Expo Floor tours, and live chat. For the price of an internet connection, you can pull most of the value into your living room. Or your standing desk. Or, if you're like me, a porch in the early morning before the household wakes up.

The Avaratak Take

As an Atlassian Solution Partner, I get to watch how big announcements actually translate into customer outcomes — usually about three to six months after the spotlights cool down. Here's what I tell our clients about events like Team '26: the announcements are exciting, but the real win is in the planning conversation that happens after.

If you're attending, come back with three things.

- The product capabilities you want to pilot in the next 90 days.

- The cultural shifts you want to start nudging your team toward.

- The names of two or three peers you want to keep talking to throughout the year.

That's a strategy worth the price of admission.

If you can't attend, watch the keynote, pick one demo that genuinely excited you, and let's talk about what it would look like to put it to work in your environment. That's the whole point of having a partner who's paying attention to the roadmap so you don't have to.

What Comes Next

I'll be watching Team '26 closely, taking notes that nobody asked for, and bringing the most useful nuggets back to this blog. If a specific session has you curious — or you're trying to decide whether to send your team — drop us a line at avaratak.com. That's exactly the kind of conversation we love to have.

The teams that win the next five years won't be the ones with the flashiest AI demos. They'll be the ones with a clear-eyed plan for how AI fits into their operating model, their culture, and their day-to-day rhythm. Team '26 is one of the better places I know to sharpen that plan with real customer stories, real product demos, and real peer conversations — all in the same three days.

May the right ideas find your team this Team '26 season. And may your hotel coffee actually be drinkable. (A blogger can dream.)

Let me tell you about the moment everything changed for me.

It was a Tuesday — because chaos always seems to prefer Tuesdays — and our team had just missed a critical product deadline. Not because people weren't working hard. Not because the ideas were bad. But because nobody actually knew who owned what. Tasks lived in email threads, Slack messages, and one very optimistic spreadsheet that hadn't been updated since February.

That was the day I got serious about Jira.

And I haven't looked back since.

What Is Jira, Really?

Most people hear "Jira" and immediately think: software developers. Bug tracking. Sprints. Standups. And yes, Jira is absolutely the gold standard for software development teams. But here's what surprises people — Jira is so much more than a dev tool. It's a work management platform that adapts to how your team actually operates, whether you're shipping code, launching marketing campaigns, onboarding new hires, or managing a legal review process.

Atlassian built Jira to give teams a single source of truth. One place where work lives, breathes, and gets done. And once you experience that kind of clarity, going back to the spreadsheet chaos feels unthinkable.

The Use Cases That Will Make You Rethink Everything

Here's where it gets interesting — and where most people leave opportunity on the table.

Software Development Teams are the obvious starting point. Jira's Scrum and Kanban boards let engineering teams plan sprints, track bugs, manage backlogs, and release software with confidence. The ability to link issues directly to pull requests and deployments creates a transparency that keeps everyone — from developers to stakeholders — on the same page.

Marketing Teams are quietly becoming some of Jira's biggest fans. I've seen content teams use Jira to manage editorial calendars, track campaign deliverables, and coordinate cross-functional launches with the same discipline that engineering teams bring to a product release. When your blog post goes through the same structured workflow as a software feature, quality goes up and missed deadlines go down.

HR and People Operations teams use Jira to manage onboarding workflows, track open roles through a hiring pipeline, and coordinate policy updates across departments. Instead of buried email chains, every task has an owner, a due date, and a status that anyone can check at a glance.

IT and Operations teams rely on Jira Service Management — Jira's service desk-focused sibling — but even standard Jira works beautifully for managing internal IT requests, infrastructure projects, and compliance checklists.

Why Jira Is Genuinely Awesome

I know "awesome" gets thrown around a lot. But hear me out.

What makes Jira stand apart isn't just the feature list. It's the philosophy baked into the product. Jira believes that visibility creates accountability. When work is visible, people own it differently. When progress is trackable, blockers surface faster. When history is searchable, teams stop reinventing the wheel.

The reporting and dashboard capabilities alone are worth the conversation. Custom dashboards let you surface exactly the metrics your team cares about — velocity, cycle time, open bugs by priority, work completed this sprint. You stop guessing and start knowing.

And the integration ecosystem? Jira connects with over 3,000 apps in the Atlassian Marketplace. Slack, Figma, GitHub, Salesforce, Zoom — your existing tools plug right in. Work doesn't have to live in silos just because your tools are different.

Tips and Tricks That Actually Change How You Work

I've spent years in Jira, and these are the moves that made the biggest difference for me and the teams I've worked with.

Use Epics to think big, then break it down. Epics are your high-level goals — think "Launch Q3 Product Campaign" or "Migrate to New Infrastructure." Under each Epic, you build out Stories and Tasks. This top-down structure keeps the big picture visible while daily work stays granular and actionable.

Automate the repetitive stuff. Jira's built-in automation rules are a game changer. You can automatically assign issues when they hit a certain status, send Slack notifications when a bug is marked critical, or close out subtasks when a parent issue is resolved. I set these up once and they quietly save hours every single week.

Labels and components are your best friends. Don't underestimate how much a well-tagged Jira board can speed up your work. Labels let you filter issues by theme, team, or initiative across projects. Components help you group work by feature area or system. Combined, they make search and reporting dramatically more powerful.

Customize your workflows. Out of the box, Jira gives you a solid workflow. But the real magic happens when you tailor it to how your team actually moves work forward. Add a "Waiting on Client" status. Create a "Ready for QA" step. Build in a review gate before anything goes to done. Your workflow should reflect your reality — not the other way around.

Use the Roadmap view for stakeholder communication. When a VP asks "where are we on the Q4 initiative," you want a clean visual answer — not a 47-issue board dump. The Jira Roadmap view gives you a timeline-based overview of Epics and their progress. It's the view that makes executives feel confident and keeps everyone aligned on what's coming.

A Real-World Story That Stuck With Me

A mid-sized e-commerce company I worked with had a recurring nightmare every peak season: last-minute feature requests, unclear ownership, and developers finding out about a critical promotion two days before launch. Sound familiar?

We rebuilt their entire product delivery process inside Jira. Marketing started logging requests as Epics with business context attached. Engineering triaged those requests in a shared backlog. Stakeholders could see status in real time without scheduling a single update meeting.

Their first peak season post-implementation? Zero missed launch commitments. The team described it as the first time in three years they actually felt in control. That's not a product feature. That's a cultural shift enabled by the right tool.

The Bigger Picture

Here's what I've come to believe after years of working in and around the Atlassian ecosystem: the teams that win aren't always the ones with the most talent or the biggest budgets. They're the teams with the clearest sense of what needs to happen, who owns it, and what done looks like.

Jira gives you that clarity.

It's not just a project tracker. It's the connective tissue that turns a group of talented individuals into a coordinated, high-performing team. And once your team experiences what it feels like to work with that kind of structure and visibility, the old ways of working start to feel like a distant, slightly painful memory.

The Tuesday chaos that derailed us? It doesn't happen anymore. And that, honestly, is everything.

Let me tell you about the most expensive number I've ever read in a productivity report.

According to Atlassian's research, the average knowledge worker spends over a quarter of their week looking for information. A quarter. Of every week. Searching for the document that exists somewhere, the decision someone made on a call last month, the spec that lives in a Slack thread, the dashboard that the previous team owner set up before they left for greener pastures.

If you've felt this in your own bones, congratulations — you're sane. If you haven't, your team has either solved this problem or they're hiding it from you.

I lead with that because it's the real reason Atlassian's Teamwork Collection exists. Not the marketing brochure reason. The "we got tired of watching smart people waste hours of their week on glorified scavenger hunts" reason. And once you understand what the Collection is genuinely solving, the price tag stops looking like a bundle discount and starts looking like an apology for how much value it's returning to your week.

What the Teamwork Collection Actually Is

Teamwork Collection is a curated bundle of Atlassian's most-used apps — Jira, Confluence, and Loom — supercharged by Rovo agents and stitched together by Atlassian's Teamwork Graph. The Premium and Enterprise tiers also include Guard Standard for security governance, which becomes increasingly important the more your AI is touching the more sensitive corners of your stack.

The simplest way to describe it: instead of buying four products that happen to sit next to each other in the same vendor's catalog, you're buying a connected system where context follows the work. A Loom video becomes a Confluence page. A Confluence page spawns Jira tasks. A Jira ticket pulls in the right Loom recording when someone joins the project late. Rovo sees it all and answers questions across the entire stack without you having to remember which tool the answer lives in.

That's the headline. Now let me get to why it matters in dollars and Tuesdays.

The Numbers That Made Me Sit Up

Atlassian publishes some honest research on what changes when teams adopt the Collection. A few of the data points that caught my attention:

92% of teams spend less time searching for information. Translation: the quarter-of-the-week scavenger hunt I mentioned earlier shrinks dramatically when knowledge actually lives in one connected place.

29% fewer meetings. Loom is doing real work here. When async video can carry context, the "do we even need a meeting?" question gets a real answer instead of a reflexive yes.

75% faster project delivery. That's not a typo. When teams can plan in Jira, document in Confluence, communicate in Loom, and let Rovo agents handle the connective tissue, the gap between "we should do this" and "we shipped it" gets remarkably short.

Up to 40% cost savings versus buying the apps separately. The bundle math actually works. Rivian, currently running the Collection, reportedly saves $2.5 million annually by centralizing on this stack — a 36% reduction in tooling cost.

I cite vendor numbers cautiously, because every vendor publishes hopeful research. These aren't hopeful. They line up with what I see when I work hands-on with teams who've actually adopted the Collection. The before/after on time-to-decision and time-to-delivery is genuinely visible within a couple of months.

What the Rovo Agents Quietly Do

The piece I keep underestimating in conversations is how much of the heavy lifting Rovo agents do once they're in the picture. A few of my favorites:

Brainstorm Facilitator sparks ideas in Confluence whiteboards using context from your team's history. Less "blank page anxiety," more "wait, that's actually a great direction."

Diagram Creator turns a discussion into a clean, AI-generated diagram. The kind of thing that used to take a determined PM 45 minutes now takes 90 seconds.

Workflow Builder lets you describe a Jira workflow in plain English and have it built — statuses, transitions, rules, the whole assembly. Even your most allergic-to-automation team members will quietly love this one.

Meeting Insights Reporter synthesizes decisions and action items across your Loom recordings, including across multiple meetings. The compounding value is enormous when you're trying to reconstruct what was decided three months ago without scrolling through five videos.

And those are the out-of-the-box options. With Rovo Studio, your team can build custom agents tuned to your exact processes — no PhD required, no AI-engineering hire mandated.

The Real-World Workflow That Sells Itself

Here's the workflow that closes the deal in client conversations.

A product lead has a new feature idea. Instead of scheduling a 60-minute kickoff meeting, they record a 4-minute Loom walking through the concept. Loom transcribes it. Rovo turns the transcript into a structured Confluence page with the key decisions and open questions surfaced. From that Confluence page, Rovo creates the corresponding Jira tasks — properly typed, assigned to the right people, with summaries that actually make sense.

The team gets the kickoff context in 4 minutes of their own choosing. Confluence has a real artifact, not a meeting recap nobody will reread. Jira has a clean backlog the engineering team can start grooming.

Total meetings required: zero. Total context lost: also zero. That's the whole pitch in one workflow.

Where Avaratak Comes In

A few honest words from the trusted-advisor seat.

The Teamwork Collection is a tremendous deal — if your team is ready for it. If your Confluence is currently a graveyard of 2019 onboarding docs, if your Jira workflows haven't been touched since the original admin left, if Loom feels like "that thing we tried once" — adopting the Collection won't fix those underlying problems. It will amplify them.

That's where we come in at Avaratak Consulting. As an Atlassian Solution Partner, our job is the unsexy part: helping clients clean up the foundation before bolting on the AI brain. We audit your existing footprint, surface the orphan content, redesign the workflows that no longer match how your team actually operates, and get Rovo plugged into the system in a way that compounds value instead of magnifying mess.

Done well, the Collection pays for itself within a quarter. Done in a hurry, it becomes a 40% bundle discount on the same scattered chaos you started with. The difference between those two outcomes is almost entirely about preparation, and it's the most consequential conversation we have with clients right now.

Worth Saying Out Loud

Productivity tools have made a lot of grand promises over the past decade. Most of them under-delivered. The Teamwork Collection is one of the rare cases where the integration actually compounds — where one plus one plus one plus AI ends up being noticeably more than four. The teams I see getting the most out of it aren't the ones with the biggest budgets. They're the ones who took the foundation work seriously and let the system do its job.

If you're curious whether the Collection makes sense for your team, that's exactly the conversation we love. Stop by avaratak.com and let's talk about your scavenger-hunt problem before the next quarter of weeks gets eaten by it.

I'll let you in on a small secret about how I read Atlassian announcements: I scroll fast, looking for the one sentence that makes me stop. When the Software Collection news landed, my stop-and-reread moment came from Atlassian's CTO, Rajeev Rajan, describing his own engineering team's experience inside the new tools. He wasn't pitching. He was reporting — the way someone reports about a tool they actually live in — and that shift in tone is the whole story of what Atlassian just did.

That moment matters because the announcement is a genuinely big deal — and Bitbucket is sitting right at the center of it. If you've been thinking of Bitbucket as “the Git host we use because it integrates well with Jira,” it's time to update that mental model. Quickly.

The Pivot Hiding in Plain Sight

Atlassian recently introduced the Software Collection, which is the company's official answer to a question every engineering leader has been quietly asking: how do I know whether all this AI investment is actually making my team better?

The Collection bundles five products — Rovo Dev, Bitbucket Pipelines, Bitbucket, Compass, and DX — into one cohesive AI-native software development lifecycle. That word, cohesive, is the one I want you to underline. Atlassian isn't just selling tools that happen to integrate. They're selling a system where the same context flows from a customer ticket in Jira, through a pull request in Bitbucket, into a deployment in Pipelines, into a service catalog in Compass, into productivity insights in DX. One thread. End to end.

And Bitbucket, which has spent years quietly being the dependable Git workhorse, just got promoted from “tool we use” to “platform our AI partner runs on.” Big difference.

What's Actually New for Bitbucket

A few changes deserve real attention.

Hybrid licensing. Bitbucket is now available in cloud and hybrid licenses, which is a meaningful shift for clients juggling regulatory requirements, legacy on-premises code, and the relentless pull toward cloud-native workflows. We've had several conversations recently with clients who needed to keep certain repositories close to home for compliance reasons but wanted everything else in the cloud. Hybrid finally gives them an honest answer instead of a workaround.

Rovo Dev runs through Bitbucket natively. This is the quiet headliner. Rovo Dev — Atlassian's AI teammate that just hit general availability — handles automated code reviews and acceptance-criteria checks directly in Bitbucket pull requests. It debugs failing pipelines. It can take a Jira issue, branch the code, write the commits, and open the PR for review. Notice that workflow. The developer's job stops being “type the boilerplate” and starts being “review the boilerplate, refine the logic, ship the value.” Anyone who's spent a Sunday afternoon writing a CRUD endpoint they could describe in two sentences will appreciate the math.

Pipelines parent-child artifact sharing. A smaller update with outsized impact for teams running complex CI/CD setups. Bitbucket Pipelines now allows artifacts to be shared between parent and child pipelines, which removes one of the more annoying friction points in modular build architectures. If that sentence meant nothing to you, congratulations — you don't have this pain. If it meant everything, you already know why I'm calling it out.

The DX acquisition completes the loop. DX is joining the Software Collection to bring real engineering intelligence into the picture — measuring AI adoption impact, surfacing where developer flow breaks, and giving leaders honest data about whether their tooling investments are paying off. For Bitbucket users specifically, this means the question “is the team actually faster now?” finally has a credible, measurable answer rather than a Slack poll.

Why I'm Pointing This Out to Clients

When Atlassian shares its own internal data — developer satisfaction climbing from 49% to 83% in three years, pull requests per engineer up 89% — that's not a marketing flex. That's a customer reference, and the customer happens to be the company that built the tools. They ate the dog food and the dog food worked.

Here's the part I find genuinely exciting as a trusted advisor. For years, Bitbucket has been the underrated sibling in the Atlassian family — beloved by the engineering teams using it, often overlooked in cross-functional strategy conversations because “we already have Git somewhere.” The Software Collection changes that conversation entirely. Bitbucket becomes the substrate that AI runs on, the place where business context (from Jira and Confluence) meets code reality (in repositories and pipelines), and the surface where productivity insights (from DX) get their measurements.

If you're a client of ours running Bitbucket today, you've been quietly sitting on a strategic asset. The next year is when that quietly becomes obvious.

What Avaratak Is Telling Customers Right Now

A few practical recommendations.

Audit your current Bitbucket footprint. Before you bolt on Rovo Dev or pull DX into the conversation, get clear on what repositories live where, who owns them, and how they're integrated with Jira. Most teams I work with discover at least one “orphan” repo or a CI pipeline nobody fully understands anymore. Clean that up first. The AI tools work dramatically better when the underlying topology is clean.

Pilot Rovo Dev on a real workflow, not a demo project. The temptation is to test new AI tools on a sandbox with throwaway code. Resist it. Pick a real, modestly complex feature — something with a Jira ticket, an acceptance criteria document in Confluence, and a pull request that needs reviewing. Let Rovo Dev work through it end-to-end. You'll learn ten times more in one week of real use than in a month of demos.

Evaluate hybrid licensing if you've been stuck on cloud migration. I've watched too many clients hold off on cloud benefits because one division has compliance requirements that complicate the picture. Hybrid licensing is genuinely a new option, not a rebrand of an old one. Worth a serious look if the cloud-or-die conversation has been stalled in your environment.

Plan for DX before it lands. When the DX integration arrives in Software Collection, the teams that have already cleaned up their Bitbucket and Compass setup will get value on day one. The teams that haven't will spend three months untangling data before they see a single insight. Front-load the cleanup.

The Bigger Picture

Bitbucket isn't trying to win the “best Git host” trophy anymore. It's positioning itself as the developer platform inside the AI-native SDLC, with Rovo Dev as the brain, Pipelines as the muscle, Compass as the org chart, and DX as the dashboard. The pieces fit together intentionally, and the customer who treats them that way will get exponentially more value than the customer who treats Bitbucket as a standalone Git tool.

If you're an engineering leader weighing where to make your next tooling investment, this is the conversation worth having. We've spent years helping organizations get the most out of the Atlassian platform, and the shift toward an AI-native SDLC is the most consequential one we've seen in a decade. The teams that move thoughtfully and early will compound advantages quarter after quarter. The teams that wait will spend the next two years catching up.

If you'd like a partner to help you map your current state to where the Software Collection is going — and to do it without the breathless hype that usually surrounds anything with “AI” in the description — that's exactly what we do at Avaratak Consulting. Stop by avaratak.com when the timing's right.

Picture the moment.

Your service desk admin has been at it for three hours. They've got a new onboarding workflow in JSM. New hires submit a request, and depending on the department, the location, and whether the role requires a security clearance, the request needs to spawn three different kinds of work in three different projects, with different approvers, different SLAs, and different welcome packages. They've been wrestling with Jira Automation rules, building one branch, then another, then realizing the conditions don't quite chain the way they need them to.

Eventually they Slack me. "Can Avaratak help? I think Jira Automation has officially given up on me."

And I smile, because I know exactly what conversation we're about to have. It's the one where I introduce them to ScriptRunner, and a problem that took three frustrated hours becomes a single, elegant Groovy script that runs in milliseconds.

This blog is about that conversation.

A Quick Refresher

Jira Service Management is Atlassian's IT service management platform — the spiritual evolution of the old service desk, now a full-fledged ITSM tool with request management, incident management, change management, and Assets all baked in. We wrote a love letter to it earlier this year, and it remains one of the most under-appreciated jewels in the Atlassian portfolio.

ScriptRunner is the Adaptavist-built, Groovy-powered Swiss Army knife that lives on top of Jira (and JSM specifically). It's been the most popular app on the Atlassian Marketplace for years, and for good reason. ScriptRunner gives JSM admins direct access to logic the native UI doesn't expose — custom post-functions, listeners, scripted fields, scheduled jobs, REST endpoints, and (finally, by end of March 2026) Behaviours for JSM Cloud.

Together, they're a service desk power combo that's hard to beat.

The Complementary Truth Nobody Says Out Loud

Here's the honest framing I give every client.

Jira Automation handles roughly 80% of the automation needs you'll have on JSM. It's no-code, it's included with your subscription, and Atlassian keeps making it more capable. For the bread-and-butter rules — auto-assigning tickets, sending notifications, transitioning statuses — Jira Automation is genuinely all you need.

ScriptRunner handles the other 20%. The branching logic that has too many conditions to express in a no-code rule. The integration with the third-party identity provider that needs custom REST work. The scripted field that calculates cost-of-delay across three different exchange rates. The scheduled job that audits stale change requests every Tuesday at 2 AM and quietly closes the ones that have been ignored.

That 20% is where the most valuable automation hides. And it's usually the part that defines whether your JSM feels like a generic ticket queue or a thoughtful service experience.

The right question isn't "Jira Automation or ScriptRunner?" The right question is "where does each one belong in our toolkit?"

Five Ways ScriptRunner Earns Its Keep on JSM

Let me get specific.

Complex decision branching. The onboarding scenario I opened with? In Jira Automation, you'd be stitching together conditional branches that quickly become unreadable. In ScriptRunner, it's a single script that reads the department, location, and clearance fields, and creates the right child issues in the right projects with the right approvers. One source of truth. One place to debug.

SLA-aware escalation. Native SLAs in JSM are good. But what if you need to escalate a P1 ticket only when the assignee has been unresponsive for 60 minutes and the request has high VIP scoring and the customer is in a paid support tier? ScriptRunner can read all of that, decide, and act. The escalation that used to be a phone call at midnight becomes a quiet Slack ping to the on-call manager.

Custom post-functions. When a request is resolved, fire off a personalized email that includes a CSAT link tied to that customer's locale. When a change is approved, automatically generate the corresponding pull request in Bitbucket. When an incident is closed, write the post-mortem stub into Confluence with the right template and the right owner. These are the tiny workflow finishers that turn JSM from a queue into a polished service experience.

Scripted fields. Native custom fields are static. Scripted fields are alive. A refund-amount field that automatically converts to the customer's currency. A risk-score field that recomputes based on the affected services. A sentiment field that pulls from the linked customer success record. The data your team needs, available where they need it.

REST API integrations. ScriptRunner's REST endpoints let JSM talk to the rest of your stack in either direction. Pull customer records from Salesforce when a support ticket is created. Push incident data to PagerDuty when severity changes. Sync change requests with your asset CMDB. The integrations that would have required a developer sprint become a thoughtful afternoon for a JSM admin who knows their Groovy.

What's New for 2026

The headline coming out of Adaptavist's roadmap is that Behaviours support for JSM Cloud is shipping by the end of March 2026. If you've used Behaviours on Jira Software, you already know why this is exciting. If not, here's the elevator pitch: Behaviours let you dynamically control fields on a form — show, hide, mark required, set values, validate inputs — based on what the user has already entered. On a JSM portal, that turns clunky, intimidating request forms into smart, conversational experiences that only ask for what's actually relevant.

This one is worth planning for now. The teams that have their request types and field libraries cleaned up will be ready to roll Behaviours out on day one. The teams that haven't will spend a quarter untangling things first. Front-load the cleanup.

The Avaratak Take

A few honest words from the trusted-advisor seat.

ScriptRunner is genuinely powerful, and that means it deserves real governance. I've seen Jira instances with 200+ ungoverned scripts, no documentation, no ownership, and a quietly ticking time bomb of "what does this even do?" If you're going to invest in ScriptRunner, invest in the practice around it: name your scripts, document them, assign owners, review them quarterly, and treat them like code — because they are.

Three practical recommendations we give clients adopting ScriptRunner on JSM.

Start with the impossible 20%. Don't try to rebuild your existing Jira Automation rules in Groovy just because you can. Find the one workflow that's been bugging your team because Jira Automation can't quite express it, and let ScriptRunner solve that. Win small, win specific.

Pair scripts with knowledge. Every ScriptRunner workflow we deploy gets a corresponding Confluence page documenting what it does, why it exists, and who owns it. This habit alone will save your team weeks of forensic work two years from now.

Plan for Behaviours. Audit your JSM request types and forms now, so you're ready to make them dynamic and intelligent the moment Behaviours lands.

Worth Saying Out Loud

Most JSM teams discover ScriptRunner after they've spent days trying to force-fit Jira Automation into a use case it was never going to handle. We try to spare our clients that detour. The smart move is to know which tool to reach for from the start — and to have a partner who's seen enough JSM workflows to spot the impossible 20% before it eats your sprint.

If you're staring at a JSM workflow that just won't behave, that's exactly the conversation we love at Avaratak Consulting. Stop by avaratak.com and bring the workflow that's been giving you trouble. Odds are very good there's an elegant ScriptRunner answer waiting for it.

There's a special category of professional event where, the morning after, you find yourself staring at a cold hotel coffee drawing arrows between napkin notes because everything suddenly connects. I've walked out of exactly three conferences in my career feeling that way. Two of them were Atlassian events.

‍

So when the dates for Team '26 landed on my calendar, I may have done a small happy dance that my office cat found highly suspicious.

‍

Let me tell you why this year's event deserves your attention — whether you're flying to Anaheim or watching from your kitchen.

‍

The headline facts

Team '26 runs May 5-7, 2026 at the Anaheim Convention Center. The theme this year is "Unlock human-AI collaboration at scale," and Atlassian is calling it the global conference for AI-forward teams, their leaders, and the apps and agents that fuel them. That phrasing is not accidental. Atlassian is telling us, in plain English, where the entire portfolio is heading.

‍

If you can't make it to Southern California, here's the part I genuinely wish more vendors copied: there's a free digital pass. The livestream runs May 6-7, and the on-demand library drops on May 11. You can register without spending a dollar, which means the "I'm too busy for this" excuse has officially run out of steam.

‍

Why this year's Team matters more than usual

‍

Here's the curiosity-gap question I'd want to ask a room full of product and IT leaders: if the single biggest shift in your tech stack over the next twelve months weren't going to be a tool, but a teammate, would you change how you plan FY27?

‍

That's the premise of Team '26. Atlassian has spent the last two years quietly building the connective tissue between Jira, Confluence, Loom, Jira Product Discovery, Jira Service Management, and Rovo — and now the AI agents are walking onto the floor. The May 7 livestream is specifically dedicated to putting AI teammates to work with specialized skills that help every team work faster and smarter.

‍

Atlas Camp 2026 in Amsterdam previewed some of this back in March. Teamwork Graph now has connectors and APIs that let developers add external data and build apps and agents on top of it, and Forge-hosted LLMs powered by Amazon Bedrock let developers ship AI features without having to manage model infrastructure. Translation: the platform is opening up, and the ecosystem is about to get very interesting.

‍

If you're the person at your company who owns the "how does work actually happen here" question, Team '26 is the three-day masterclass you didn't know you'd been waiting for.

‍

The speaker lineup is, in a word, stacked

‍

Mike Cannon-Brookes, Atlassian CEO and co-founder, will be on the mainstage — and he has a long history of announcing the things everyone has been waiting for. Joining him:

‍

Ethan Mollick, the Wharton professor and artificial intelligence thought leader, whose book Co-Intelligence has become mandatory reading for anyone trying to think clearly about AI and knowledge work. Emily Chang, the Emmy Award–winning journalist who can interview her way out of any soundbite. And Alexis Ohanian, Reddit co-founder and founder of Seven Seven Six — a guy with strong, tested opinions about community, platforms, and what makes teams actually work.

‍

That's not a "we booked whoever was available" lineup. That's a curation.

‍

The part nobody puts in the brochure

‍

Here's what I tell every client who asks whether Team is worth the flight: the keynotes are great, but Team is really won on the Expo Floor, in the hallway conversations, and during something Atlassian calls Braindates. These are one-on-one and group conversations on topics you want to discuss — only available at Team '26. In my humble opinion, it's the single best-designed networking mechanic at any tech conference. You post a topic you care about. Other humans sign up. You meet. You talk about that specific thing. No small talk. No forced icebreakers.

‍

Add in 1:1 sessions with Atlassian product experts, the Atlassian Williams F1 Team presence (yes, the F1 partnership is on display — bring a camera), and some very persuasive numbers from past attendees: 96% of attendees learned something that helped solve a business challenge. 88% of companies found new solutions and tools. 78% connected with product and solution experts. And 305 companies attend as a team with two or more people.

‍

Those numbers are, if anything, conservative based on what I've seen from clients who've gone.

‍

How we're thinking about Team '26 at Avaratak

‍

As an Atlassian Solution Partner, here's the honest frame I'm giving our clients who are on the fence:

‍

If you're evaluating a major Atlassian expansion, consolidation, or migration in the next 12 months, go. In person. You'll compress three months of vendor calls into three days, and you'll make decisions with more confidence on the plane home.

‍

If you're an Atlassian admin or platform lead, go. The 1:1 support sessions alone are worth the pass, and you'll leave with a peer network that saves you hours every month for years.

‍

If budget or calendar just won't cooperate this year, grab the free digital pass today. Block May 6 and 7 on your calendar. Watch the keynotes live. Bookmark the on-demand library when it goes live May 11. Then bring what you learned to your team lead. And if you want a thinking partner to debrief with, we'll be taking notes too.

‍

The one group I'd gently push hardest to attend in person: leadership teams who are still treating AI as a "we'll figure it out next quarter" item. Team '26 is going to be less a feature announcement event and more a crash course in what human-plus-AI collaboration actually looks like at scale. That's a tectonic shift, and the organizations that move first set the pace for their industries.

‍

The forward-thinking bit

‍

We talk with clients all the time about the difference between adopting tools and rewiring how work happens. The first is a line item. The second is a competitive advantage. Atlassian is very clearly building toward the second, and Team '26 is where they're going to show us what it looks like when every team — not just engineering, not just product, not just IT — has AI teammates with specialized skills working alongside them.

‍

Whether you're flying to Anaheim or firing up the livestream from your kitchen, you're going to leave with a sharper picture of what the next two years of teamwork will actually look like. That is, objectively, a good use of a Tuesday through Thursday in May.

‍

If you want to compare notes on the sessions worth prioritizing, need help building a business case to bring your team along, or just want to know where to get the good coffee near the convention center, our inbox is open at avaratak.com. Anaheim in May — we'll be there.

‍

See you on the Expo Floor.

‍

Hope you’ve had a fantastic week of crushing tasks, dodging needless meetings, and maybe even soaking up some summer sun. If your calendar has been anything like mine, you’ve probably felt that little zing of joy when a meeting gets canceled at the last minute. (No shame, we all know that feeling!) This week Atlassian dropped a slew of juicy blog posts, and the star of the show is a new AI-powered solution that promises to make meeting overload a thing of the past. Yes, you read that right: Atlassian’s Loom team is on a mission to unstick our meetings and give us our sanity back. Let’s dive in, shall we?

‍

Picture this: it’s mid-week, you’ve got back-to-back Zooms, and your to-do list is growing cobwebs. Meetings are a staple of modern work life, but too often they feel like obligatory time-sinks rather than productive collaborations. Atlassian hears our collective sighs. In their August 6 blog post “Unstuck your meetings: Loom’s new AI for productive meetings,” they introduce a smarter way to tackle meeting madness. The tone is upbeat (with a wink to our universal love of canceled meetings) and the message is clear – the future of meetings is here, and it’s powered by AI. Cue the confetti, because maybe, just maybe, meetings can become… enjoyable? 😲

‍

So what’s the scoop? Atlassian’s latest trick up its sleeve is Loom AI for Meetings, a transformative tool that brings cutting-edge artificial intelligence right into your conference calls. Essentially, Loom’s new AI is like having an extremely diligent personal assistant in every meeting (minus the coffee runs). It records your meetings and does all the heavy lifting afterward: automatically generating meeting notes, pulling out action items, and even emailing a recap to everyone involved. And it does all this without you lifting a finger – or even attending the meeting at all, for that matter! (Finally, you can skip that 7 a.m. status call and still know exactly what happened. 🙌)

‍

Let’s break down how Loom’s AI is supercharging our meetings in a few key ways:

‍

Effortless recording & smart summaries: Just hit record (or let Loom auto-join) and you’re done. The AI captures every detail of the discussion and then produces an organized summary of the meeting. No more frantically scribbling notes or trying to remember what Alex from accounting said 30 minutes in – Loom’s got it all documented neatly for you. It’s like having a court stenographer and an executive assistant in one, except you don’t have to provide snacks.

Never worry about missing a meeting: Have a calendar conflict or need to be in two places at once? No problem. Loom’s AI-generated notes and action items ensure that even if you miss the live meeting, you won’t miss a thing. You can confidently play hooky from the call (we won’t tell 😉) and catch up on the outcomes later. Imagine skipping the meeting and still being the most informed person in the room – sounds almost like a superpower.

Works wherever you work: One of the coolest parts is that Loom’s AI isn’t tied to a single platform. Whether your team lives on Zoom, Microsoft Teams, Google Meet, or all of the above, Loom integrates with your calendar and meeting tools to slipstream into your workflow. There’s no complex setup; you connect Loom to your calendar, set your preferences, and voilà! The AI will join and handle the note-taking magic regardless of which video meeting platform you’re using. It’s the definition of “work smarter, not harder.”

Customize and stay in control: Worried about privacy or TMI in your recaps? Atlassian’s thought of that. Loom AI for Meetings gives you fine-grained control over which meetings get recorded and who receives the summaries. You decide if that casual Friday team banter needs an official recap (maybe not!) or if it’s just the big project meetings. You can also set link access permissions for the meeting recordings and notes. In short, you’re the boss of your meeting data – the AI just does the busywork, exactly how you want it done.

After rolling out these immediate benefits, the blog post gets us even more hyped by painting a picture of what’s coming next. Atlassian hints that the future of meetings is even more integrated into our daily tools. Soon, Loom’s AI meeting insights will funnel seamlessly into the Atlassian apps we already use and love. No more scattered info across different platforms or digging through old emails to find that one decision from last week’s call. Here’s a peek at what’s on the horizon:

Automated Confluence pages: Loom AI will be able to auto-publish your meeting notes straight into Confluence. Each note will include key information like who was in the meeting, what action items were assigned to whom, any links shared during the call, and more. Your Confluence workspace could soon have a living, searchable record of all important discussions – basically turning talk into documented knowledge without any manual effort.

Jira integration for action items: You know those tasks that get tossed around in a meeting – “Sarah, can you follow up on X?” or “We’ll need a ticket for Y bug fix” – and then sometimes they vanish into the ether? Loom AI will make sure that doesn’t happen. It’s going to automatically convert next steps into Jira issues, assigning them to the right folks. So instead of leaving a meeting with a vague sense that you have more work to do, you’ll have concrete Jira tickets waiting. Your future self, logging into Jira, will thank you.

Unified search across everything: The vision is that all the knowledge captured in meetings (notes, decisions, action items) will become discoverable across Atlassian’s suite. Think of it as a giant cross-app brain. Need to recall if a certain feature was approved in a meeting? You could search in Confluence or Jira and the answer pops up because it was all indexed from the Loom meeting notes. One source of truth for all your teamwork – chef’s kiss.

Reading about these upcoming features honestly feels like peeking into a not-so-distant utopia of work, especially for those of us juggling multiple projects and meetings. Atlassian’s basically saying: meetings don’t have to be a black hole where time and productivity vanish. Instead, with AI assistance, meetings can become a launchpad for action and clarity. Discussions turn into documented decisions, tasks don’t fall through the cracks, and team members (present or not) stay in the loop. It’s like turning the messy kitchen of meetings into a well-organized, self-cleaning wonderland.

And if all this sounds a bit revolutionary, Atlassian certainly thinks so too. They’re inviting everyone to give Loom’s AI a try and see how it transforms your team’s collaboration. The vibe from the blog is enthusiastic and optimistic – and a little contagious. It’s hard not to imagine a world where you actually look forward to meetings (wild, I know!) because you trust the system to handle the tedious parts while you focus on the creative and important stuff.

Before we sign off, let’s take a moment to appreciate the big picture here. Atlassian acquired Loom not too long ago, and it’s clear they’ve been busy turbo-charging it with their own AI prowess (hello, Rovo and pals). This week’s highlight demonstrates Atlassian’s ongoing commitment to solving those everyday workplace headaches with smart tech and a wink of humor. Whether it’s a machine learning deep-dive like Rovo Deep Research or practical tips for better work management, there’s a common theme: making work life better for teams everywhere. And what’s more “work life” than meetings? Fix those, and we’re all living the dream!

Alright, that’s a wrap for this week’s Atlassian update. If you’ve ever daydreamed about a world where “this meeting could have been an email” is no longer a lament but a solved problem – well, Atlassian is on it. Here’s to hoping your next meeting practically runs itself, and you get back some precious time (maybe to read more Atlassian blog posts or enjoy a coffee in peace). 😄 Have a fantastic week ahead, and catch you next time for more Atlassian goodies! Until then, happy collaborating and may all your meetings be productive and shorter than scheduled. Cheers!

‍

Without clear documentation, communication suffers, information gets lost, and teams become misaligned. Confluence offers a solution: it’s a wiki-style platform that allows teams to create, organize, and manage documentation in a shared space. Whether you’re maintaining an internal knowledge base, project docs, or product manuals, Confluence provides a flexible, collaborative environment to streamline your documentation process. This guide covers how to structure your Confluence spaces, create and organize content, and maintain documentation quality over time.

Why Use Confluence for Documentation?

Confluence is purpose-built for team documentation and offers several advantages over traditional tools like Word documents or static PDFs:

Single source of truth: All pages live in a centralized, searchable space, eliminating version confusion and scattered files. Team members always access the latest information in one place.

Real-time collaboration: Multiple users can edit or comment on a Confluence page simultaneously, making knowledge-sharing seamless and avoiding lengthy email threads.

Structured organization: You can organize content with spaces and pages in a hierarchy, keeping documentation logically grouped and easy to navigate.

Powerful search: Confluence’s built-in search and filters help users quickly find the pages or details they need.

Integration with other tools: It links up with issue trackers, chat apps, and more – for example, you can reference Jira issues or embed Trello boards – connecting your documentation to your team’s workflows.

Access control: Robust permissions settings let you control who can view or edit content, so sensitive information stays secure.

Many organizations already leverage Confluence to improve their documentation workflow. For example, tech startups often create internal wiki pages for onboarding and developer guides, support teams maintain Confluence knowledge bases for troubleshooting, larger enterprises document their policies and SOPs, and software companies publish user guides or API docs in Confluence for customers. In each case, Confluence serves as a collaborative hub where anyone can easily find up-to-date information.

Getting Started: Setting Up Your Confluence Space

Plan your structure from the start. A little upfront organization will save everyone time later. When you first create a space for documentation, consider the following setup steps:

Create dedicated spaces: Organize documentation into separate spaces for different teams or projects. For example, you might have one space for Engineering docs, another for HR policies, and another for Product documentation. This keeps content segmented at a high level and relevant to the audiences who need it.

Set up permissions: Decide who can view or edit each space (and even each page) to maintain security and content integrity. Give editing rights only to those who should contribute, and view rights to a broader audience as needed. Proper permissions prevent unauthorized changes and accidental edits.

Plan the page hierarchy: Within each space, plan a logical page tree. Decide what the top-level pages should be and how child pages will nest under them. For example, under a Project space, you might have top-level pages like “Project Overview,” “Design Docs,” and “Release Notes,” with multiple sub-pages under each. This nesting helps users browse content without getting lost.

Use clear naming conventions: Establish a consistent naming scheme for pages. Descriptive, consistent page titles (e.g. Project Alpha – Onboarding Guide instead of just Onboarding) make it easier to identify content at a glance and improve search results. Consistent naming also prevents confusion that can arise from duplicate or unclear titles.

Setting up your Confluence space with a thoughtful structure ensures that as your content grows, it remains organized and easy to navigate. A well-structured space will spare your users the “Where did that page go?” scavenger hunt, because information will be logically placed and accessible.

Creating and Editing Pages in Confluence

Once your space structure is in place, creating pages is straightforward. Confluence provides an intuitive editor and plenty of tools to help format content clearly:

Page creation: Click the “Create” button in the navigation bar to start a new page. You can choose from a template or begin with a blank page.

Editing and formatting: Write your content and use the rich text editor to format it. Apply headings and subheadings to section your page, use bullet points or numbered lists for steps and key points, and add tables or info panels as needed. These elements break up text and make pages more reader-friendly. Confluence also supports macros – special content blocks – to add dynamic elements like status labels, page includes, etc.

Multimedia: Insert images, diagrams, or even videos/screenshots to illustrate important concepts. Visuals can greatly enhance understanding by showing an example interface or a flowchart of a process. Drag-and-drop attachments or use the “Files & Images” button to add media.

Saving and versioning: When finished, hit “Publish” to save the page. Confluence will keep track of every edit in the page history. This means you can always view or roll back to previous versions if needed, giving you version control without the headache of multiple file copies.

Encourage your team to follow common style guidelines when editing (like using the same heading levels or terminology across pages) to keep the documentation consistent and professional.

Organizing Content with Spaces, Pages, and Sections

A clear content structure is critical for findability. Confluence offers multiple levels of organization to keep your documentation tidy:

Spaces: Use spaces as top-level containers to group related content by department, project, or purpose. For instance, have a Marketing space, an Engineering space, a Product Help Center space, etc. This high-level separation prevents unrelated pages from mixing together and confusing users.

Page hierarchy (page tree): Within a space, pages can be nested hierarchically under parent pages. Arrange your pages in a logical tree structure under broad topics. For example, in a “Company Policies” space, you might have a top-level page for each category of policy, with individual policy pages as children. Nesting pages under relevant parent pages helps users browse the content structure logically.

Top-level pages: These are the main sections or categories within a space. Think of them as the table of contents for that space. Examples might be “HR Policies,” “IT Guidelines,” or “Project Roadmaps.” Each top-level page should cover a distinct category of information.

Sub-pages: These are the individual content pages that fall under a top-level category. For example, under HR Policies (top-level) you could have sub-pages like Leave Policy, Remote Work Policy, etc. This way, related topics are grouped together and easy to find.

Sections within pages: Even on a single Confluence page, structure the content for readability. Use headings and subheadings to break the page into sections, use bullet lists or numbered steps where appropriate, and consider using Confluence’s expandable sections (expand macros) for lengthy optional details. This makes each page more scannable, so readers can quickly jump to the part they need.

A well-structured Confluence space with a clear page hierarchy makes it much easier for team members to navigate and locate information. Conversely, if pages are dumped in a flat list or organized haphazardly, people will waste time hunting around. Take advantage of Confluence’s hierarchical structure to map out content in a logical way that mirrors how users think of the topics.

Structuring Your Documentation for Success

Great documentation isn’t just about what you write – it’s also about how everything is organized. Even high-quality content can become useless if it’s buried in poorly structured pages or scattered across an incoherent system. To avoid this, invest time in designing the structure of your documentation:

Plan before you create: Before adding a bunch of pages, step back and outline an information architecture. Think about the key types of documents you will have, who the audiences are, and how people will look for that information. This planning helps prevent redundancy and confusion down the line.

Consider these points when planning your documentation structure:

Identify key documentation needs: What content is essential for your team or project? List the main categories of information (e.g., development docs, onboarding guides, SOPs, FAQs). Also consider who will be using the documentation and what their top questions are – this can guide how you group and prioritize content.

Define a logical hierarchy: Decide on broader categories under which related pages will live. Group related content under a common parent or within the same space. A clear hierarchy (like Space > Section Page > Sub-page) prevents having dozens of uncategorized pages and helps users understand context.

Maintain consistency in format: Establish a style guide for your Confluence pages – for example, decide on standard heading sizes, page layouts, or terminology. Consistent formatting and tone across pages make the knowledge base feel cohesive and professional, and it helps users acclimate to the structure more quickly.

By thoughtfully planning your documentation layout and standards, you set a solid foundation that will serve you as content grows. It’s much easier to expand an organized system than to reorganize a messy one later!

Using Labels, Links, and Macros for Easy Navigation

After setting up a clear hierarchy, you can further enhance navigation and discoverability using Confluence’s features like labels and links:

Apply labels (tags): Labels are keywords you attach to pages. They act like tags and make content more searchable and filterable. For example, you might label certain pages as “how-to”, “policy”, or “release-notes”. Users can then search or click a label to find all related pages. Labels essentially provide alternate ways to group and find content (think of them as cross-cutting categories that aren’t reflected by the page tree).

Create cross-page links: Within your pages, link relevant content to each other. If one page references a topic explained in detail on another page, insert a hyperlink to that page. Internal links help readers jump to background information or related guides without manual searching. For instance, your onboarding guide can link to the IT setup page, or a troubleshooting article can link to the general FAQs.

Use the Children Display macro: On overview or parent pages, consider using the children display macro (or the built-in page tree view) to automatically list sub-pages. This creates an on-page list of all pages nested under the current page. It’s especially useful on a main page that serves as a hub for multiple topics – the macro will show a live-updating menu of all child pages, so readers can see what sub-topics are available.

Insert a Table of Contents: For lengthy pages with many sections, add the Table of Contents macro at the top. This automatically generates a list of links to all headings on the page. It provides readers with an outline of the page and lets them jump directly to a section of interest (much like an article’s summary with anchor links). This is great for long documentation pages or manuals, as it improves navigation and user experience.

By tagging content thoughtfully and linking pages together, you create multiple pathways for users to find information. Someone might browse the space’s page tree, filter by a label, or follow an inline link from one page to another – in all cases, they’re able to navigate your Confluence knowledge base with ease and discover relevant content naturally.

Leveraging Templates for Consistency and Efficiency

Creating every page from scratch can be time-consuming and can lead to inconsistency. Confluence addresses this with built-in templates for common documentation needs. You can use these templates as a starting point to ensure important information isn’t omitted and that pages have a consistent structure:

Built-in Confluence templates: Confluence comes with several handy templates out-of-the-box. For example, you’ll find templates for Meeting Notes, Project Plan, Product Requirements, Retrospectives, and more. Using a template, a new page will be pre-formatted with useful sections and placeholder text guiding what to write (e.g., an agenda and action items section in a Meeting Notes template). This helps maintain consistency across similar pages and reminds authors to include key details.

Custom templates: If your team has specific types of documents, you can create your own templates. To do this, design a page with the layout and headings you want standardized, then save it as a template (space admins can create global or space templates). For instance, you might create a template for “Technical Design Doc” that includes sections for Overview, Architecture, Diagrams, etc. Once saved as a template, anyone creating a new page can use it. This ensures new documentation pages follow the established format.

Encourage template usage: Train your team to use these templates whenever applicable. Provide a quick how-to if needed, or even include links on an onboarding page directing users to “Create page from template.” When everyone uses the templates, your Confluence pages will have a uniform look and structure, which helps readers know where to find certain information on any page.

Some best practices for managing templates:

Name templates clearly: Use descriptive names for your templates so their purpose is obvious. For example, “Incident Report Template” is better than “Report Template”. Clear names help authors pick the right template and ensure consistency.

Keep templates updated: Periodically review your templates, especially if processes change. If you find people always add a certain section to pages, consider updating the template to include it by default. Remove or adjust any parts of templates that are no longer useful. Regularly refining templates keeps them relevant and valuable.

Share across teams: If multiple teams or departments could benefit from a good template you’ve made (e.g., a “How-To Article” template for support documentation), make it available globally or share it with those teams. Consistency across the organization’s documentation can improve overall quality and readability.

Using templates effectively means authors spend less time on format and more on content. It results in a more predictable and professional documentation experience for your readers.

Encouraging Collaboration in Confluence

One of the greatest strengths of Confluence is how it enables team collaboration on documentation. Embrace these collaborative features to keep documentation dynamic and inclusive:

Real-time co-editing: Confluence allows multiple people to edit the same page at once. This live collaboration means a project team can, for example, work together on a project plan document simultaneously without overwriting each other’s changes. Everyone sees updates in real time, which prevents version conflicts and eliminates the need to merge different contributions later. The result is a single page with combined input, rather than multiple disparate files.

Automatic version history: Every time a page is updated, Confluence tracks the changes. Team members can view the page history to see who changed what, when. They can also compare versions or restore an earlier version if a mistake was made. This version control gives peace of mind – no edit is ever truly lost, and any errors can be rolled back.

Inline comments and page comments: Encourage the use of comments for feedback and discussion. Users can highlight specific text on a page and add an inline comment (which appears like a margin note tied to that text). This is great for pointing out a section that needs clarification or suggesting an improvement exactly where it applies. Additionally, comments at the bottom of the page allow broader discussion. This built-in feedback loop means suggestions and questions stay with the content, instead of getting lost in emails or chat threads. It’s an easy way for subject matter experts to review and for others to ask questions right in context.

Easy sharing: Confluence pages are accessible via URLs, which makes sharing simple. Instead of emailing documents around, just send someone a link to the Confluence page. They’ll always see the latest version. You can also use Confluence’s share feature to send a page to specific users or groups with a personal note, which notifies them to check it out. This beats sending attachments and worrying if people have the right version.

Notifications and watch pages: Users can watch pages or entire spaces to get notifications when there are updates. This is useful for key documentation that a team must keep an eye on (such as a frequently updated spec or a changelog). The watchers will be alerted whenever someone makes a change or adds a comment, which helps stakeholders stay informed about updates in real time.

Additionally, Confluence integrates with other collaboration tools to fit into your team’s ecosystem:

Jira integration: If your organization uses Jira for issue tracking or project management, you can embed Jira issues or filters on Confluence pages. For example, a release notes page can display the list of Jira tickets completed in that release, automatically updated. This keeps documentation and development work in sync. Developers and project managers often link Confluence design docs or requirements pages to related Jira issues as well, providing context in both directions.

Slack or Microsoft Teams: By connecting Confluence to your messaging platform, you can receive instant notifications in chat when pages are edited or commented on. For instance, a Slack channel can get a notification “Page X was updated by Jane Doe” with a link. This keeps the team aware of changes without having to constantly check Confluence. It’s also possible to use chat-bots or slash commands to search Confluence from Slack, accelerating knowledge retrieval.

Other integrations: Confluence supports embedding content from tools like Trello, Google Drive, draw.io, and many others through macros or add-ons. If your team uses Trello boards for tracking tasks, you can embed a board on a Confluence page for a project status overview. If you have diagrams, the draw.io integration allows direct editing of diagrams within Confluence pages. Leverage these integrations to make your Confluence pages a true single-stop hub for all project information.

By fostering a culture of collaboration around your Confluence documentation, you ensure that the knowledge base stays active and up-to-date. Team members feel ownership and are more likely to contribute improvements or corrections. Ultimately, a collaborative approach turns documentation from a static reference into a living, evolving resource for the whole team.

Maintaining and Updating Your Documentation

Creating high-quality documentation is only half the battle – keeping it accurate, up-to-date, and relevant is just as important. Over time, software changes, processes evolve, and pages can get stale. Here are some best practices to ensure your Confluence documentation stays valuable and doesn’t fall into disuse:

Regularly Review and Update Content

Set a routine to audit and refresh your documentation:

Establish a review schedule: It’s a good practice to periodically review pages (for example, quarterly or biannually) to check if the information is still current. Put a reminder on your calendar or assign this in your project management tool. Regular audits prevent outdated procedures or data from lingering unnoticed.

Assign content owners: For each important page or section, designate an owner (a specific person or role) responsible for its accuracy. When someone is accountable for a page, they are more likely to update it when things change. For instance, make the HR manager the owner of the HR Policies space, or the lead developer the owner of the API docs page. If content ownership is clear, updates happen faster.

Use analytics or feedback to prioritize updates: If you have Confluence Premium, you can use page analytics to see which pages get the most views – high-traffic pages should never be outdated. Even without advanced analytics, gather feedback from your team about which documentation is most critical, and focus maintenance efforts there. Pages that are rarely visited might be candidates for archiving or consolidation, whereas frequently used pages deserve extra attention to keep perfect.

By keeping to a regular update cycle, you’ll catch content that needs fixing (broken links, old screenshots, retired features, etc.) before it becomes a problem. Fresh content maintains trust – users know they can rely on the documentation because it’s been reviewed recently.

Control Access with Proper Permissions and Workflow

Maintaining documentation quality isn’t just about the content, but also about how content gets edited. Without any control, well-meaning users might clutter or accidentally alter important pages. Take advantage of Confluence’s permissions and consider workflow processes to manage contributions:

Limit who can edit critical pages: Not everyone in your organization needs edit rights on all pages. For crucial or highly polished documentation (like official policies or published product docs), consider restricting editing to a small group of maintainers. Other employees can still propose changes via comments or by editing a copy, but the main page stays protected from accidental changes.

Use page permissions and restrictions: Confluence allows you to restrict pages so only certain people or groups can edit (or even view) them. Use these judiciously. For example, you might allow open editing on a brainstorming page but lock down a “Master Plan” page to project leads only. This balance keeps content both collaborative and reliable where it matters.

Implement an approval workflow for changes: For documentation that must be verified (like compliance-related docs or user-facing knowledge base articles), establish a review process. This could be a simple team agreement (e.g., any changes must be reviewed by a senior team member) or facilitated by an add-on app that supports approvals before publishing. Having an editorial workflow ensures that content is reviewed for accuracy and consistency before everyone sees it.

Manage external access carefully: If you use Confluence to share documentation with clients, vendors, or the public, segregate that content and apply the right permissions. Confluence can allow anonymous access or guest accounts for external users in specific spaces. Make sure those external-facing spaces don’t inadvertently expose internal-only information. Also, keep a tighter review cycle for externally visible pages, since they represent your company’s knowledge to outside readers.

By controlling editing rights and using workflows, you maintain a high standard of quality and prevent the chaos of too many cooks in the kitchen. It’s not about stifling contribution – rather, it’s about guiding it so that the knowledge base remains trustworthy.

Archive Outdated Content

Over months and years, documentation can pile up. Some of it becomes obsolete as projects end or policies change. It’s important to declutter by archiving or removing old content, so people don’t get confused by outdated information:

Archive old pages instead of deleting: If a page is no longer relevant, consider moving it to an Archive space or an Archive section within the space, rather than deleting it outright. For example, you might create an Archive space where you move all pages related to completed projects or past years’ policies. Make that archive read-only. This way, the content is out of the main navigation and search (unless specifically searched for), but you still have it on hand in case someone needs historical information.

Label or mark deprecated content: Another approach (or additional step) is to add a clear label like “archived” or “obsolete” to pages that are no longer maintained. You can even put a note at the top of the page – e.g., “Note: This page is archived and is no longer updated.” This warns readers that the content is outdated. Confluence’s page properties or a status macro can be used for a visible indicator.

Display last updated dates: Confluence automatically shows the last modified date at the bottom of each page. Make sure this is visible, or use a “Last updated” info panel at the top of pages for high-visibility. If a page hasn’t been touched in two years, readers should see that and treat its content with caution. Teams sometimes implement a “Last Reviewed on [date]” line on each page, updated manually or via a macro, to signal content freshness.

Prune during audits: When doing your regular content review, identify pages that are duplicates, outdated, or irrelevant. Clean them up – either update them, merge them with other pages, or archive them. Removing clutter makes it easier for everyone to find the current, correct information. It also reduces search noise (so irrelevant old pages don’t keep showing up in search results above the useful ones).

Archiving is like housekeeping for your wiki. By tidying up old content, you ensure that team members navigate a clean, relevant knowledge base. They won’t be distracted or misled by legacy pages that linger around. Plus, your documentation will load them with confidence that what they are reading is up-to-date.

The first time someone suggested we use Jira Service Management, I rolled my eyes. Hard. I pictured a clunky ticketing system where requests go to die, where emails bounce around endlessly, and where the phrase 'Did you try turning it off and on again?' lives rent-free in every response template.

I was wrong. Spectacularly wrong.

And the moment I realized it? I was watching a new employee complete her entire onboarding — equipment requests, software access, HR forms, and IT setup — through a single, clean portal. No emails. No Slack pings. No confusion. Just a smooth, trackable, accountable flow from day one.

That's when Jira Service Management stopped being a tool to me and started being a strategy.

What Jira Service Management Actually Is

At its core, Jira Service Management (JSM) is Atlassian's IT service management platform — but calling it just that is like calling a Swiss Army knife a toothpick. Technically accurate in one dimension, wildly underselling the full picture.

JSM brings together service request management, incident management, change management, and asset management under one roof. It's built on the same powerful Jira platform that development teams already love, which means it plays beautifully with the rest of your Atlassian stack. That alignment between dev and ops teams? That's not an accident. It's the whole philosophy.

The Use Cases That Will Actually Surprise You

Here's where it gets interesting — and where most people leave value on the table.

IT Support (The Obvious One): Yes, JSM is fantastic for IT help desks. You get customizable request forms, SLA tracking, automated triage, and a self-service portal that actually reduces ticket volume because users can find answers themselves. But you already knew that. Let's go deeper.

HR Service Delivery: This is the one that opens eyes in every demo I've ever seen. HR teams can use JSM to manage everything from new hire requests to leave approvals and policy questions. One company I worked with cut their onboarding coordination time by creating a single HR portal where managers submitted new hire details and JSM automatically triggered a checklist across IT, facilities, and HR simultaneously. The days of seventeen-email chains were over.

Legal and Compliance Requests: Legal teams are flooded with ad-hoc requests — contract reviews, NDA approvals, compliance questions. When those land in inboxes, they get lost. When they land in JSM with priority levels, due dates, and audit trails, they get handled. I've seen legal departments go from reactive chaos to proactive, trackable workflows in a matter of weeks.

Facilities Management: Office move requests, equipment maintenance, room bookings — facilities teams are often running on spreadsheets and goodwill. JSM gives them the same structured, accountable workflow that IT teams have enjoyed for years. It levels the playing field across the organization.

Developer-Facing Support: Because JSM lives in the Atlassian ecosystem, development teams can link service requests directly to Jira Software issues. A bug report from a customer becomes a ticket in the service portal, which links directly to the engineering backlog. The loop closes faster. The customer feels heard. The developer has context. Everyone wins.

Why It's Genuinely Awesome

What makes JSM stand apart isn't any single feature — it's the compounding effect of several things working together.

The customer portal is clean, branded, and intuitive enough that even the least technically inclined team members use it without training. That alone reduces friction dramatically.

The SLA management feature is something I personally rely on. You set the rules — respond within two hours, resolve within one business day — and JSM tracks it automatically, escalates when needed, and gives you reporting to spot patterns. When I noticed that password reset requests were consuming a disproportionate amount of SLA time, that data led directly to implementing a self-service password reset that cut those tickets by 60%.

The automation engine is where I spend a lot of happy hours. You can auto-assign tickets based on request type, send proactive updates to customers when ticket status changes, escalate tickets that are approaching SLA breach, and trigger alerts when incidents hit a certain priority level. No code required. Just logic, applied consistently.

And then there's Assets — JSM's asset and configuration management tool. Knowing which laptop is assigned to which employee, tracking software licenses, and linking assets directly to incident tickets changes the game for IT teams. Instead of asking 'What computer are you using?' in every ticket, the asset is already linked. The context is already there.

Tips and Tricks I Wish I'd Known Earlier

Start with your most painful workflow, not your most complex one. Every team has that one process everyone complains about. Start there. A quick win builds momentum and trust in the platform.

Use request types generously. Don't make people choose from a giant generic form. Create specific request types — 'New Software Access,' 'Hardware Replacement,' 'Visitor Wi-Fi' — so the form fields are relevant and the routing is automatic. Your agents will thank you.

Build your knowledge base from day one. JSM integrates natively with Confluence, which means you can surface relevant help articles right inside the customer portal. Every time you resolve a common request, write a short Confluence article. Over time, your self-service resolution rate climbs and your ticket volume drops. It compounds beautifully.

Set up queues with intention. Default queues are fine for getting started, but custom queues — sorted by SLA urgency, customer tier, or request type — make your agents significantly more effective. I once reorganized a team's queue structure in an afternoon and watched their average resolution time drop within a week.

Don't skip the post-incident review templates. JSM has built-in support for incident management with post-incident review features. Using them consistently builds institutional knowledge and prevents repeat incidents. The five minutes you spend documenting what happened saves hours the next time something similar occurs.

A Real-World Moment That Sticks With Me

A mid-sized marketing agency I consulted with had a problem: their creative team was constantly blocked waiting for IT to provision new software tools, and IT had no visibility into what was coming. Requests arrived by Slack, by email, sometimes by someone literally walking to the IT person's desk.

We built them a simple JSM service desk in under a week. Creative submitted requests through the portal. IT got automatic notifications with all the context they needed. Managers got visibility into request status without having to ask. Within a month, average provisioning time dropped from four days to less than one. The creative team felt respected. The IT team felt organized. Leadership had a dashboard showing actual data for the first time.

Nobody changed how hard they worked. They just changed how that work flowed.

That's what Jira Service Management does at its best. It doesn't replace effort — it respects it. It takes the energy your teams already have and channels it somewhere it can actually land.

If you've been sleeping on JSM, or if you've only been using it for basic IT tickets, I genuinely encourage you to look again. The version of the tool in your head is probably smaller than the one waiting for you.

I want to tell you about a meeting that didn't happen last Tuesday.

One of our clients — a director of customer support at a mid-sized SaaS company — was supposed to walk her newest team lead through the right way to handle escalations in their JSM portal. Twenty-five new request types. Seven SLA tiers. Four custom approval flows. The kind of walkthrough that usually swallows 90 minutes, leaves both people exhausted, and gets only half-absorbed because nobody can take notes that fast.

Instead, she recorded a 12-minute Loom on Sunday night while her kids were in bed. The new lead watched it Monday morning, paused on the parts she needed, asked a few specific follow-up questions in the Loom comments, and was running real escalations by lunch.

The 90-minute meeting that didn't happen is the whole story of why Loom and Jira Service Management work so well together. And it's a story I find myself telling clients almost weekly now.

Two Tools That Solve Adjacent Problems

On the surface, Loom and JSM look like they live in different neighborhoods.

Jira Service Management is Atlassian's ITSM platform — the home for service requests, incidents, change management, and Assets. It's where your team's structured work lives. Tickets. SLAs. Workflows. Approvals. Audit trails. Everything that needs to be tracked, prioritized, and accountable.

Loom is Atlassian's async video tool — the home for your team's spoken work. The walkthrough that's faster to record than to type. The bug reproduction that's clearer to show than to describe. The customer follow-up that's warmer with a face attached than with a paragraph of plain text.

The reason they're powerful together is that most service work is genuinely both. A great ticket has structure and context. A great handoff has accountability and nuance. Loom gives JSM the texture; JSM gives Loom the spine. Put them in the same workflow and your service team stops choosing between speed and clarity — they finally get both.

The Five Workflows That Earn Their Keep

Let me get specific about where this combo actually shines.

Bug reports that don't require a translator. A customer hits an error in your product. Instead of submitting a ticket that reads “something's broken,” they record a 60-second Loom showing exactly what they did, what they expected, and what happened instead. The Loom URL goes in the JSM ticket as a custom field or in the description. Your engineering team doesn't have to play detective. The reproduction steps are the recording. Mean time to first response drops noticeably the moment you make the Loom field part of your customer-facing request form.

Internal walkthroughs that scale. The escalation walkthrough I opened with. Onboarding a new agent. Showing the team how a recent JSM workflow change actually behaves. These are the moments where typing instructions feels like a punishment for everyone involved. Record one Loom. Attach it to the relevant Confluence page or pin it inside the JSM project's documentation. Anyone who joins the team in the next 18 months gets the same crisp walkthrough without you reliving Tuesday morning.

Status updates that respect the customer's time. When a complex incident is in flight, customers want to know what's happening — but they don't want a 600-word email. A 90-second Loom from your incident commander explaining current state, expected resolution time, and what the customer should do in the meantime is dramatically more reassuring than the same content written down. Drop the Loom URL into the JSM incident ticket and into the customer-facing comment, and you've simultaneously updated the audit trail and the human relationship.

Change advisory board (CAB) reviews that don't require a meeting. Most CAB conversations are 10% genuine debate and 90% explanation of context. Have the change requester record a 5-minute Loom walking through the proposed change — the why, the rollback plan, the testing done. Attach the Loom to the JSM change request. CAB members watch async, on their own time, and only the changes that genuinely need debate show up in a real meeting. The CAB transforms from a calendar tax into a focused decision body.

Knowledge base articles that get written. The biggest unsolved problem in most JSM implementations isn't process — it's documentation. Articles don't get written because writing is hard. With Loom, your senior agents record themselves walking through a tricky resolution they just completed. Confluence converts the Loom transcript into a structured page (this used to be manual; the new Rovo agents in the Teamwork Collection do it for you). The article exists in 15 minutes instead of 2 hours, and the next agent who hits the same problem actually finds it.

The Quiet Power of Linked Context

Here's the part that doesn't get talked about enough. When a Loom URL lives inside a JSM ticket, the relationship is permanent and searchable. Two years from now, when someone is investigating a similar incident, they don't just find the ticket — they find the recording of how it was actually handled. Institutional memory stops walking out the door when employees do.

Multiply that across hundreds of tickets and dozens of agents over a few years, and you've built something genuinely valuable: a video-augmented operational memory that grows naturally as your team works. No documentation initiative required.

The Avaratak Take

A few honest words from the trusted-advisor seat.

The Loom + JSM combo is a force multiplier, but it works best when you make a few deliberate choices early.

Add a “Loom URL” field to your most-used request types. Don't wait for agents and customers to know they can attach Looms. Put a clearly labeled field in the request form that says “Attach a quick Loom recording (optional but encouraged).” Adoption goes from “sometimes” to “default” almost overnight when the field is sitting there waiting.

Set up a Loom workspace that mirrors your JSM project structure. When your Loom recordings are organized by service team or product area the same way your JSM projects are, the search experience for your team becomes seamless. Otherwise you end up with hundreds of Looms in a flat library nobody can navigate.

Use Loom AI's transcript and summary features. Every Loom now generates a transcript and an AI-written summary automatically. Paste either of those into the JSM ticket alongside the Loom URL. Future agents who can't watch the video at that moment still get the searchable text. Audit-friendly. Skim-friendly. Future-proof.

Train your senior agents to record short, not long. The temptation is to record a polished, comprehensive 20-minute video. Resist it. The best Loom-to-JSM workflow I see consistently uses recordings under 5 minutes. Short recordings get watched. Long recordings get bookmarked and forgotten.

Worth Saying Out Loud

Most service teams know they have a knowledge-capture problem. Most service teams also know they have a meeting overload problem. Loom and JSM, working together, quietly solve both — not with a grand strategic initiative, but with a small, daily habit of capturing the spoken context that already lives in your team's heads and parking it next to the structured tickets where it belongs.

The director who recorded the Sunday-night walkthrough? She told me last week that her team's average handle time on complex escalations dropped 18% in the first quarter after they made Loom-on-tickets a default behavior. She didn't run a formal program. She just made it easy, and the team did the rest.

That's the pattern I'd want every JSM team to find for themselves. If you'd like a partner to help you wire it up thoughtfully — from request-type design through Loom workspace structure through the small training nudges that actually drive adoption — that's exactly the kind of work we love at Avaratak Consulting. Stop by avaratak.com and let's talk about your team's next 90-minute meeting that doesn't have to happen.