zoltanersek _outpostlabs_dev_ Atlassian Partner

mostly at my grandparents, it was great because it was the only time in the year when I could see some of my friends, they only visited their grandparent during the summer break 

Use Components (or a dedicated custom field) to identify the affected service or infrastructure area. Use Issue links to model cross-service dependencies instead of relying on nested subtasks. Keep automation focused on business events (e.g., "deployment blocked", "dependency resolved") rather than specific technologies.…

That's such a great system. It's not so elaborate where I live, you just go and get a book, that's all. Great tip with the free tour, I'll check it out next time I'm in LA

Another thing to verify is whether your Plan hierarchy is configured to display Stories. If your roadmap is set to show only higher-level work items (such as Epics or above), Stories won't appear regardless of their status.

I like the direction Atlassian is taking with treating the knowledge base as the foundation for AI rather than as a standalone documentation repository.

great read, I like using resolved work items to identify knowledge gaps

One additional thing to verify is where the list in the email is coming from. If you're using {{lookupIssues}} in the email body, make sure the Lookup issues action is using the corrected JQL as well.

So cool to see this. It's great to see Forge developers supported via this program. 

Wow, they really take their lemons seriously there

great article, I like your point about keeping JQL focused on scope and letting the reporting tool handle dates and SLA metrics

That is sooo frustrating to me as well, if I don't type in the thing from the beginning it doesn't show up, I want it to work with just the numbers

You're definitely not the only one. This comes up quite a bit, especially for teams that estimate both parent issues and subtasks and want that total visible directly on the board. I'd be interested to hear whether anyone has found a clean native workaround. It seems like a good candidate for a feature request, especially…

Nice summary. I think the biggest takeaway is that Confluence's native tools answer either "What can this user access?" or "What restrictions does this page have?", but not "Who has access to all sensitive content?" Once a space grows beyond a few dozen pages, that becomes a challenge. That's why I also like your…

I've found it useful to treat configuration changes like application releases: bundle them, document them, and review their impact together. Not only does that reduce reindex cycles, but it also makes troubleshooting much easier when someone asks, "What changed last week?"

Congratulations! 🎉 One thing I really like about your approach is that you emphasize understanding over memorization. That's probably the biggest difference between passing an exam and actually becoming a better Jira professional.

One additional recommendation I'd make is to use this transition as an opportunity to clean up workflow sprawl. Most organizations don't revisit workflows unless they're forced to, and a platform change like this is the perfect trigger.

One thing I'd add is that "used" doesn't always mean "valuable." Some Marketplace apps are only touched by a handful of admins but are absolutely business-critical (think workflow extensions, automation, or security apps), while others may have lots of clicks but little real impact.

Great first article! I really like that you focused on the architecture and design decisions rather than a click-by-click tutorial. Those tend to age much better as Cloud evolves.

Thanks for documenting this, posts like these are incredibly valuable because they capture the "unknown unknowns" that release notes rarely mention.

I'm curious to how you're measuring added value as well, adoption sometimes is not great at showing this. Those are much harder metrics to collect though

I always enjoy discovering little small features that make my life better, I'd love some improvement around clearer visibility into which identity is currently "active" myself

Thanks, those are solid improvements. One issue I keep noticing is the author panel on the up right corner is stale with data. Sometimes it shows the author's photo, but the info is about me. 

I like the huma in the loop principle. I think that's the right balance. One thing I'd probably add is moving from pull based to push based. Most delivery health today still depends on someone opening a dashboard or reviewing a board. The real value comes when the agent proactively nudges the right person at the right…

thank you, this will make things so much easy to read on large screens

Thank you jira admins for keeping everything running 

Every detail lives in jira already, so agents running the cloud can just pick them up and open PRs directly. Maybe I won't even have to open Jira, is that the intention of the Atlassian team? :D Talk to jira via slack, have an agent automatically open a pr and review in bitbucket/github

Those are really clever automations, I will steal some of them :D 

I'm also interested in this, the mcp should impersonate the user using it from my opinion.

One area I'm really excited about is retros. AI can summarize what happened during a sprint, but I think the bigger opportunity is helping teams identify recurring patterns instead of just producing meeting notes. I'm really curious what "cycle-time trends and flow patterns surface right from issue history, making…

I'm trying to get back to baking more frequently. But I'm also on a diet, so it makes this difficult :D