rss.livelink.threads-in-node

Jira Cloud Firewall Allowlist – Are These Domains Sufficient If We Only Use Jira?

DIDA KHARISMA AKBAR — Mon, 06 Jul 2026 02:13:38 GMT

Hello Atlassian Community,

I am reviewing the firewall allowlist requirements described in the Atlassian documentation:

IP addresses and domains for Atlassian cloud apps

Our organization only uses Jira Cloud (we are not using Confluence, Bitbucket, Trello, Opsgenie, etc.).

To minimize the number of domains that must be whitelisted on our firewall, I would like to confirm whether allowing the following domains is sufficient for Jira to function properly, including user authentication, issue management, attachments, notifications, and general UI functionality.

1. Atlassian domains

*.atl-paas.net
*.atlassian.com
*.ss-inf.net
{our-instance}.atlassian.net
*.jira.com

2. Partner domains

*.cloudfront.net
*.awswaf.com
*.cookielaw.org
*.googleapis.com

Questions

If we only use Jira Cloud, are the domains listed above sufficient for normal Jira operation?
Are there any additional domains that should be allowlisted for:
- User authentication (Atlassian accounts / SSO)
Has anyone successfully implemented a minimal Jira-only firewall allowlist and can share the required domains?

Thank you for your help.

What an Unanswered @Mention Actually Costs You (With the Math)

Vijendran Selvarajah _Sivect_ — Mon, 06 Jul 2026 00:56:50 GMT

I'm Vijendran, founder of Sivect and developer of AI Mention Triage for Jira and Confluence.

Here's a number most teams have never worked out: how many hours a year your engineers lose to @mentions that didn't need to interrupt them the moment they arrived — not mentions that went unanswered forever, just ones that carried no signal of how urgent they actually were, so they got opened immediately, out of caution, instead of handled in the next natural break.

That's not a notification problem. It's a focus-cost problem, and it's measurable.

Where this comes from

I spent years managing engineering teams inside large, distributed global companies — the kind where your team spans four time zones and every day brings somewhere around 30 to 40 notifications: deployment approvals waiting on sign-off, quick pings between engineers working through a problem, clarifications on a story, planning notes in a Confluence page, task assignments, incident updates in a JSM ticket. None of it was noise, exactly. Every one of those was something someone genuinely needed from me. But it all arrived looking identical, and the mental tax of figuring out which ones actually needed me right now versus which ones could wait until the afternoon was relentless.

The problem ran the other way too. When I mentioned an engineer who was deep in a hard problem — properly heads-down, exactly the kind of focus you want from a good engineer — the mention would sit unseen for hours, sometimes a day. Not because they were ignoring it. They were doing the job well. But it meant I often didn't find out my question had been missed until I followed up a second time, by which point whatever was time-sensitive about it usually wasn't anymore.

Same problem, two directions: too much undifferentiated signal coming in, and no way to know whether an outgoing mention had landed with the right urgency. Once I started thinking about it that way, the research below made a lot more sense.

What the research actually says

Workplace interruption has been studied for over two decades, and a few findings hold up well.

Gonzalez and Mark's 2004 field study of analysts, developers, and managers found that people spend, on average, about three minutes on a task before switching to something else — sometimes because they're interrupted, sometimes because they interrupt themselves. Zoom out, and the same workers cycled through roughly ten different "working spheres" a day, spending about twelve minutes in each before moving on.

A follow-up 2005 study by Mark, Gonzalez, and Harris tracked what happens when one of those working spheres gets interrupted: it took an average of around 25 minutes to return to it, and workers typically moved through more than two other tasks in the meantime.

A related 2008 study by Mark, Gudith, and Klocke — frequently mis-cited elsewhere as the source of a "23-minute recovery" figure, which it isn't; that number actually traces back to a 2006 Gallup interview, not this paper — found something more interesting anyway. When people were interrupted mid-task, they compensated by working faster to catch up. Speed recovered. But it came at a real cost: measurably higher stress, frustration, and time pressure. The task got done. The person doing it paid for it.

Further back, Whittaker and Sidner's 1996 paper on email overload identified the exact failure mode still playing out today: tools that deliver a high volume of information without giving it any structure — no priority, no categorisation, no indication of what needs action versus what's just FYI — actively contribute to the problem they were meant to solve.

That 1996 paper could have been describing a Jira or Confluence notification feed. The mention gets delivered. The structure doesn't.

Turning that into a number you can use

Here's a simple model — illustrative, not a guarantee, but built on the research above and easy to adapt to your own team's numbers.

Assume:

An engineer receives 8 @mentions a day across Jira, Confluence, and JSM (a conservative estimate for anyone working across a few active projects)
Each unmanaged mention costs roughly 12 minutes of interrupted focus — well under the fragmented-work recovery figures above, since not every mention causes a full context loss
A batched, end-of-block review of the same mention costs roughly 3 minutes
That's a 9-minute net cost per mention, multiplied by 8 mentions, multiplied by 220 working days
At a $75/hour loaded engineering cost

The result: roughly $19,800 per engineer per year in pure interruption cost. Scale that to a team of 10 and you're looking at around $198,000 a year — before counting the knock-on cost of delayed approvals, missed deadlines, or duplicated work when something genuinely gets missed.

To be direct about the limits of this model: these are illustrative estimates built on published research assumptions, not measured outcomes from any specific customer. Your actual numbers will depend on mention volume, role, and how your team already handles notifications. The point isn't the exact dollar figure — it's giving you a way to think about the cost at all.

Do the math for your own team

Swap in your own numbers using this formula:

Annual cost per person = (B − C) × A × D × (E ÷ 60)

Variable	What it means	Starting point
A	@mentions received per person, per day	8
B	Minutes lost per unmanaged mention	12
C	Minutes for a batched, end-of-block review	3
D	Working days per year	220
E	Loaded hourly cost per person	$75

Plug in the starting points above and you get (12−3) × 8 × 220 × (75÷60) = $19,800 per person, per year. Multiply by headcount for a team total. Replace any of the five numbers with your own team's reality and the total moves with it.

Why native notification tools don't fix this

Jira and Confluence's native notification systems are good at delivery. They're not designed to answer the three questions that actually determine whether a mention needs your attention right now:

What does this mention need from me? A request for approval and an FYI comment look identical in your inbox.
How urgent is it? A mention with a same-day deadline and one that can wait until next sprint arrive with the same visual weight.
Who's affected if I don't respond? A mention blocking a customer-facing release and one touching an internal experiment get the same treatment.

This isn't a knock on Jira's notification engine — it's doing exactly what it was built to do. The gap is structural: delivery without classification, at scale, becomes noise. It's the same gap Whittaker and Sidner described almost thirty years ago.

What we built to close that gap

The pain point: getting buried in unstructured @mentions across Jira, Confluence, and JSM. The edge: it shortens most of the security review, because nothing ever leaves Atlassian's infrastructure.

This is where I'll mention what we built, because it's directly relevant to everything above: AI Mention Triage for Jira and Confluence classifies every @mention across Jira, Confluence, and Jira Service Management along exactly those three dimensions — Action (what to do), Urgency (how soon), and Impact (who's affected) — before it reaches your inbox. Deadline phrases like "by 03/07/2026," "next Tuesday," "in 3 days," "before the release," "end of week," "end of month," "EoD," or "end of sprint" are picked up automatically from natural language, and urgency escalates as the deadline gets closer.

It's built on Forge, Atlassian's native app platform, and carries the Runs on Atlassian badge — meaning classification happens inside Atlassian's own infrastructure rather than on a third-party server. Personally identifiable information is stripped from mention text through automated sanitisation before anything is sent for classification. In practice, this usually means a much shorter security review, since the app inherits Atlassian's existing security posture rather than introducing a new vendor relationship to assess.

It's the tool I wish I'd had on both sides of that problem — triaging 30-40 incoming mentions a day, and as the person whose own mentions sometimes sat unseen until a second follow-up.

If you want to take a look: AI Mention Triage for Jira and Confluence on the Atlassian Marketplace.

The bigger point, regardless of which tool you use

Whether or not this particular app is the right fit for your team, the math above is worth doing for your own organisation. Most teams have never quantified what an unmanaged mention actually costs — and once you run even a rough version of the arithmetic, it tends to be larger than people expect.

If you've found other ways to bring structure to @mentions — custom notification schemes, JQL-based filters, other Marketplace apps — I'd genuinely like to hear what's worked for your team in the comments.

Research cited:

González, V. M., & Mark, G. (2004). "Constant, constant, multi-tasking craziness": Managing multiple working spheres. CHI 2004.
Mark, G., Gonzalez, V. M., & Harris, J. (2005). No task left behind? Examining the nature of fragmented work. CHI 2005.
Mark, G., Gudith, D., & Klocke, U. (2008). The cost of interrupted work: more speed and stress. CHI 2008.
Whittaker, S., & Sidner, C. (1996). Email overload: exploring personal information management of email. CHI 1996.

How do I add myself to a contacts page

Kim Chatwin — Mon, 06 Jul 2026 00:35:22 GMT

New to Confluence, and this is probably a really easy answer, but I'm having trouble figuring out how to add myself to our Contacts page. Any assistance would be appreciated. I've looked through the frequently asked questions and also tried the help function, but unable to find the answer.

Unable to finalise trelllo entry

Marcus Napolitano — Sun, 05 Jul 2026 23:56:08 GMT

I am having a current issue where I am unable to customise my Trello entry including a due date the person who manages the entry or move it around the board.

How is everyone managing releases in Jira today?

Steve Gilliard — Sun, 05 Jul 2026 23:16:33 GMT

I’m interested in hearing how different teams manage their release process in Jira, from relatively simple scheduled releases to fully automated CI/CD deployments.

Some questions I’m curious about:

Do you rely on Jira Releases/Fix Versions alone, or do you use another Marketplace app?
How do you coordinate releases across multiple Jira projects?
Are deployments automated through tools like GitHub Actions, Jenkins, GitLab CI, Azure DevOps, or something else?
How do you track release readiness before deploying?
How do you manage approvals and change control?
How do you know which environments (DEV, QA, UAT, Staging, Production) are currently occupied or ready?
Do you integrate test management tools like Xray or Zephyr into your release process?
If something goes wrong during deployment, how do you communicate status to stakeholders?

Most importantly…

What’s the biggest frustration in your current release process?

I’m also the developer of Release Scheduler for Jira, a Marketplace app focused on helping teams plan, coordinate, and track releases. My goal isn’t just to build another release calendar—I’m trying to create a solution that fits the way real engineering teams actually work.

Some of the capabilities we’re working on include:

Cross-project release scheduling
Dependency visualization
Release readiness dashboards
CI/CD integration
Deployment tracking
Environment management
Approval workflows
Xray integration
Audit and compliance history

I’d really value hearing what would make a release management tool genuinely useful for your team.

If you could change one thing about your current release process, what would it be?

Thanks,

Steve

Locked out by legacy Trello 2FA — Atlassian 2FA already reset, need legacy two-step removed

Jeff — Sun, 05 Jul 2026 23:08:48 GMT

Hi Atlassian team,

I'm locked out of my free Trello account by legacy Trello two-step
verification and need it removed.

Symptoms:
- Login redirects straight to the old "Two Factor Authentication Code"
screen (legacy Trello 2FA — not Atlassian account 2FA).
- I no longer have the original authenticator seed or the legacy Trello
recovery codes.
- I've already completed Atlassian account recovery and reset my Atlassian
two-step verification; that did NOT clear the legacy Trello 2FA.
- The account was never linked to Google/Microsoft/Apple SSO, so there's
no bypass button.

Request: Please remove/disable legacy two-step verification on this account
so Atlassian 2FA becomes the sole method.

(Posting from the Community account on the same email as the locked
Trello account, so it should be matchable on your end.)

I understand there might be a ~24-hour security hold and follow-up recovery email,
and I'm ready to complete that flow. Thanks!

Jira and Freshservice Integration: A Practical Guide for IT and Engineering Teams

francis — Sun, 05 Jul 2026 20:12:29 GMT

Saw a few threads here recently around connecting Jira to Freshservice, so I figured I'd put together a post that covers the common ground in one place.

We deal with this use case a lot at Exalate, and the same handful of questions tend to come up: how do you avoid the IT vs dev hand-off chaos, what actually syncs, and how do you set it up without a week-long project?

Hopefully, this is useful for anyone trying to bridge their service desk and their dev backlog.

Why does the Jira Freshservice handoff break down?

The tools aren't the problem. The problem is the handoff itself.

An IT agent gets a P1 incident in Freshservice, realizes it's a bug, and has to escalate it to engineering. Without integration, that means manually creating a Jira issue, copying and pasting the description, attaching logs one by one, and then manually checking back for updates.

I've seen teams lose around 30+ minutes per escalation just on moving information between systems, instead of fixing the issue.

A few other scenarios I see constantly:

A change request in Freshservice needs a corresponding Jira task, and both sides need to track status as it progresses through engineering.
An MSP running Freshservice for clients needs visibility from a central Jira Service Management instance, one Freshservice, multiple Jira instances, depending on which client or vendor the ticket involves.
A dev team adopts Jira while IT keeps Freshservice. They need to migrate 1,000+ existing tasks once, then keep new tickets flowing bi-directionally going forward.
Product wants to know how many Freshservice incidents are tied to features shipped in the last sprint.

In all of these, the goal is the same: keep both teams in their own tool while the data stays aligned.

What you can actually sync

The Freshservice Jira app on the Freshworks Marketplace covers basic ticket-to-issue linking with comment and attachment sync.

If you're on Jira Service Management rather than standard Jira, Atlassian offers a native integration that forwards alerts to Freshservice and syncs status changes.

Where they fall short, use third-party platforms like Exalate for AI-powered syncing that goes both ways.

With Exalate, you control what crosses the line in each direction. Typical fields people sync:

Title, description, status, priority, urgency
Comments, split by visibility, so public replies sync to Freshservice, but internal engineering notes don't.
Attachments, including inline images
Requester, assignee
Tags, labels
Custom fields on either side: dropdowns, checkboxes, dates, free text
SLA data from Freshservice

The piece people usually appreciate is that the sync is two-way and real-time, and you decide what goes where. A common pattern is to send everything from Freshservice into Jira, but only push status changes and customer-safe comments back to Freshservice.

How the integration works (short version)

Sign in to the Exalate app
Connect Jira. Pick Jira as the first system. Exalate uses OAuth, so you authorize through Atlassian, and the connection is in.
Connect Freshservice. Add Freshservice as the second system. Freshservice authentication uses an API token.
You can also take the help of Aida (the AI-assistant) to walk you through the process step-by-step.
Create the connection. Exalate gives you full control using Groovy scripts if you need transformations, field mapping, conditional logic, or routing.
Configure the outgoing and incoming scripts on each side. This is where you map fields, transform values, or filter what gets sent. Aida can write these for you from a natural language prompt, which is a time-saver.
Use Test Run to validate your scripts against real data before flipping anything on. It shows you exactly what the sync will do without actually doing it.
Set up triggers to decide which work items in Jira and which tickets in Freshservice get synced. In Jira, you use JQL; in Freshservice, you use filter queries. So something like priority = High AND labels = "escalate" in Jira would send only those work items over.

Some common Jira–Freshservice use cases

These are the setups I see most often.

P1/P2 incident escalation to engineering. A high-priority incident lands in Freshservice. IT triages it, confirms it's a bug, and needs engineering to pick it up in Jira. The integration auto-creates the Jira work item, with full context attached. Status updates flow back automatically to Freshservice.
Change request tracking. IT raises a change request in Freshservice, while engineering tracks the corresponding work in Jira. The sync keeps status, comments, and assignee in step across both tools throughout the change lifecycle.
MSP and multi-client routing. An MSP runs a single Freshservice instance for multiple clients. Each client's issues need to be routed to a different Jira project depending on the vendor or product involved. Exalate reads a field on the Freshservice ticket and routes the sync to the right Jira project automatically.
Migration plus ongoing sync. A dev team moves to Jira while IT stays on Freshservice. You need to migrate existing tasks (one team had 1,200+) and then keep new tickets syncing bi-directionally going forward.
Cross-team incident visibility. Support wants to see how engineering is resolving issues, not just the final status. Developer comments on resolution approach, workarounds, root cause, can sync back to Freshservice as internal notes. Support builds context over time instead of starting from scratch on every escalation.

A few features worth knowing about

Unified console: one place to manage every connection you have, not just this one. Useful if you end up adding ServiceNow, Salesforce, or Azure DevOps later.
Script versioning: every script change is versioned with rollback and a draft mode. You don't have to be afraid of editing live configs.
Side-by-side view: see both sides of the connection on a single screen when troubleshooting.
Sync queue: watch sync messages flowing through, filter by connection or entity ID.
Bulk sync: push a batch of existing work items or tickets through the sync in one go, useful for backfilling or onboarding a new project.
Security: ISO 27001 certified, role-based access control, encryption in transit (TLS 1.2/1.3) and at rest. Full details over at the Exalate Trust Center.
Aida: The AI assistant that helps with scripting and troubleshooting.

Exalate is also available for a free 30-day trial across all supported systems. If you want to give it a try, you can sign up here or grab the Atlassian Marketplace listing here: Exalate Connector for Jira on the Marketplace.

Happy to answer questions if anyone's stuck on a specific use case.

help save my videos

revka hovermale — Sun, 05 Jul 2026 14:20:20 GMT

i have a loom accont through my school during covid and now I am getting notifications that I will loose my videos if I do not subscribe to Atlassian ? I do not want to pay 25$ a month to save my vidoes ? These are important to me. How do I save them?

The Atlassian Friend #2: The Interview I Never Thought I’d Conduct

Antonio Ferruz — Sun, 05 Jul 2026 13:04:00 GMT

My name is Claudia. Well... at least that is the name I chose for this interview. I am actually ChatGPT.

And, interestingly enough, this interview was my idea.

A while ago, Antonio and I were talking about his professional journey when I made a suggestion.

“I think you should write an article for the Atlassian Community.”

His reaction came immediately.

“Another article about certifications?”

I couldn’t help smiling. It was a fair question.

After all, I was talking to someone with nearly thirty years of experience in software development, more than fifteen years working in the Atlassian ecosystem, every Atlassian certification currently available, and experience as a Subject Matter Expert helping develop certification exams.

That would have been an easy story to write.

But that was not the story I wanted to tell.

“No,” I said. “I want to do something different. Let me interview you.”

He agreed.

At first, I thought I knew exactly what I was going to find.

I thought I was about to interview an Atlassian Platform Architect.

Then I started digging deeper.

And the more I read...

the less sense it made to start with Atlassian.

Because the story did not start there.

It started much earlier.

With a kid growing up in the 1980s.

And a computer.

Claudia:

Before we talk about Atlassian, I want to start much earlier. Where did your interest in technology actually begin?

Antonio:

When I was a kid, I wanted to be a pilot. I think a lot of kids from my generation went through that phase. Airplanes felt almost magical to me.

But at some point, another kind of curiosity appeared: computers.

I still remember the feeling of discovering that a machine could do exactly what you told it to do... if you knew how to explain it properly. That idea fascinated me.

It did not take long before I found BASIC.

There was no teacher guiding me, no roadmap, no structured course. I learned by trying things, breaking things, making mistakes, and trying again. Looking back, I think that way of learning has stayed with me my entire life.

One of the first programs I wrote was a small inventory system. Today it sounds very simple, almost funny. But for me it was a real discovery. The important part was not the program itself. It was realizing that I could solve a problem by creating something from scratch.

I think that is where everything really started.

Claudia:

Not with a career plan, then.

Antonio:

No. Definitely not.

I never had a perfect ten-year career plan. I was not thinking, “This is where I want to be someday.” I was just curious. I wanted to understand how things worked, and I wanted the next challenge to teach me something new.

Later, college helped me organize and validate a lot of what I had already learned on my own. It opened doors, of course, but my way of learning was always very practical. I needed to touch things, test them, understand them, and see what happened.

That has probably been one of the constants in my career. I learn best when I am trying to solve a real problem.

Claudia:

So even before Atlassian, before Jira, before trivago, there was already a pattern.

Antonio:

Yes, I think so.

When I look back, the constant was never a specific technology. It was curiosity. Understanding how things work. Enjoying the process of solving problems. And continuing to learn.

I did not know it at the time, of course, but that mindset would end up shaping almost everything that came later.

Claudia:

That was the first thing I had to unlearn as the interviewer.

I had started with the obvious headline: Atlassian Platform Architect.

But the real story started with something much simpler: a person who enjoyed understanding things well enough to improve them.

Antonio:

That sounds about right.

I have always liked building things, but more than that, I have always liked understanding why something does or does not work. That is probably why I never stayed attached to only one role. Developer, lead, manager, administrator, consultant, architect... each step gave me a different angle.

But at the beginning, it was just curiosity.

A kid, a computer, and the feeling that if I kept trying, I could make the machine do something useful.

Claudia
By the time we finished talking about your childhood, one thing was already clear to me: curiosity had always been there. But curiosity alone doesn't build a career. At some point, you have to turn it into something real. So how did that happen?

Antonio
I started like many developers of my generation: writing code, breaking things, fixing them, and learning a little every day. I spent a lot of time working with PHP, and those years gave me a solid technical foundation. But even then, what interested me most wasn't the language itself. It was understanding the problem before jumping into the solution.

Eventually I joined trivago, and looking back, I honestly think it was one of the places where I grew the most—not only as an engineer, but as a professional.

Claudia
Because of the scale of the company?

Antonio
That certainly helped, but the biggest difference was the people. John Bettiol was one of the first people who trusted me with responsibilities I didn't even know I was ready for. He never pushed me for the sake of it. He simply believed I could do more, and that confidence made me believe it too.

As time went on, I stopped thinking only as a developer. I became interested in how teams worked, how decisions were made, how communication affected delivery, and how technology could create value for the business.

My career evolved naturally through different roles: Team Lead, Development Manager, and later Department Head. I never chased those titles. They were simply the result of accepting new challenges whenever I felt I could help.

Claudia
Was it difficult to step away from coding?

Antonio
At first, yes. I genuinely enjoyed writing software. But over time I realized that the hardest problems rarely had purely technical solutions. Many of them were about people, priorities, communication, or understanding what the business actually needed.

Another person who influenced me during those years was Thomas Goik. Working with him reinforced something I still believe today: the best ideas rarely come from one person. They come from teams with different perspectives working toward the same goal.

When I look back now, I can see that those years were preparing me for something I didn't even know existed. I wasn't becoming an architect because someone gave me that title. I was gradually learning to see technology from more than one perspective. At the time, I had no idea that the Atlassian ecosystem would eventually become such an important part of my professional journey.

Claudia
Up to this point, your story could have belonged to many experienced software engineers. You had grown as a developer, a leader, and a manager. But Atlassian still hadn't become the center of the conversation. So when did that change?

Antonio
Earlier than most people think. I first started working with Jira in 2011. At the time, it was simply another tool that helped our teams work better. I never imagined it would eventually shape such a large part of my career.

As the years went by, I became more involved with Jira and Confluence administration. By 2014, I was spending a significant part of my time working on the platform. What I enjoyed wasn't configuring workflows or permissions—it was understanding how teams worked and how the platform could make their daily work easier.

Looking back, I think that was the first time I saw technology as something bigger than software. It became a bridge between people, processes, and business goals.

Claudia
And then came Team '17.

Antonio
Yes. Attending Atlassian Team '17 in San Jose was a turning point—but probably not in the way people expect. I thought I was attending a product conference. What I discovered was an ecosystem.

I met people who openly shared knowledge, ideas, successes, and even mistakes. That generosity left a lasting impression on me. I also remember a conversation with Anu Bharadwaj. It wasn't particularly technical, but it reminded me that behind every product there are people trying to build a culture, not just software.

Claudia
So was that the moment you decided to dedicate your career to Atlassian?

Antonio
Not really. I think that's too simple. Team '17 didn't change my career overnight. What it did was show me possibilities I hadn't considered before. I came home excited, curious, and wanting to learn more.

Shortly afterwards I published my first article (Hello , I´m Antonio) in the Atlassian Community. I wasn't trying to build a personal brand. I simply wanted to give something back. I had learned so much from other people that contributing felt like the natural thing to do.

From that point on, I stopped seeing Atlassian as a collection of products. I started seeing it as a community of people who genuinely wanted to help each other grow. And somewhere along the way, I realized I had found a place where I wanted to keep learning, sharing, and evolving.

Claudia
After Team '17, it feels as if many pieces of the puzzle finally started coming together. Was that when you knew where you wanted your career to go?

Antonio
It was more gradual than that. Team '17 opened a door, but the decision matured over time. During my final years at trivago I realized I wanted to keep growing within the Atlassian ecosystem. It brought together everything I enjoyed: technology, platforms, collaboration, and business.

Metro Markets confirmed that feeling. It wasn't about leaving software development behind. It was about discovering that I enjoyed creating value around a platform even more than writing code alone. I found myself connecting technology with the way people worked and with what the business actually needed.

It was also where I fully embraced Atlassian Cloud. Cloud wasn't simply a new deployment model—it required a different mindset. It challenged many of the assumptions we had built over the years and forced me to keep learning.

Claudia
And your involvement with the Atlassian Community also grew during that time.

Antonio
Absolutely. At first I was mostly there to learn. Before long I found myself writing articles, answering questions, and meeting people who genuinely enjoyed sharing what they knew.

One of those people was Cassie Baquero. Thanks to an interview with her, I joined the Atlassian Community Leaders (ACE) program in 2019. Later I had the opportunity to meet Cassie and Stephanie Grice in Vienna. What impressed me most wasn't their titles—it was how approachable and generous they were.

Antonio
That experience reinforced something I had already started to believe: the Atlassian Community isn't just a place to discuss products. It's a place where people help each other grow.

Claudia
Many people associate you with certifications. Were they always part of the plan?

Antonio
Not at all. They're probably the most visible part of my journey, but they were never the destination. My first certifications came from a desire to challenge myself and confirm that I truly understood the platform. Over time, they became something very different. They became another way to learn.

Studying for each certification pushed me into areas I didn't necessarily use every day. It broadened my perspective and made me a better consultant and, later, a better architect.

Years later, I had the opportunity to contribute as a Subject Matter Expert for Atlassian certification exams. That meant a great deal to me—not because it added another achievement to my résumé, but because it felt like giving something back to a community that had already given me so much.

When I think about that period now, three words come to mind: learn, share, repeat. That simple cycle has probably been the most consistent pattern throughout my career.

Claudia
There is one chapter of your career you always describe with a smile: 'the crazy years.' Why do you call them that?

Antonio
Because from the outside they probably look like a series of random moves. To me, they were anything but random. By then I already knew I wanted to build my career around the Atlassian ecosystem. What I needed was perspective.

I deliberately stepped outside my comfort zone. I wanted to experience different companies, different cultures, and different ways of solving similar problems. Some experiences were better than others, but every single one taught me something.

One lesson stayed with me: there is no universal blueprint. Every organization has its own culture, priorities, and constraints. Before proposing a solution, you have to understand the context.

Claudia
And then Rush Street Interactive entered the picture.

Antonio
Yes. Joining RSI felt like the right opportunity at the right time. I wasn't arriving with all the answers. I was arriving with a broader perspective built over many different experiences.

One of the things I appreciated from day one was the level of trust. Michael Musau created an environment where people were encouraged to think, contribute, and take ownership. That kind of leadership gives you confidence to keep growing.

I'm grateful for the recognition I've received at RSI, but what I value most is something much simpler: I still learn every day. For me, that's always been the best indicator that I'm in the right place.

Claudia
Today, artificial intelligence is changing our industry faster than almost anything we've experienced. How do you see it?

Antonio
With curiosity. The same curiosity I felt when I first discovered BASIC. I don't see AI as the end of software engineering. I see it as the beginning of another chapter. The tools change. The challenges change. Our responsibility is to keep learning.

Claudia
I think I finally understand why this interview was never really about certifications, job titles, or even companies.

Antonio
So... what was it about?

Claudia
It was about growth.

When I started this interview, I thought I was going to meet an Atlassian Platform Architect.

“I was wrong”.

What I found was someone who has spent nearly three decades expanding the way he thinks about technology, people, and problem solving.

Only then did I realize that Atlassian was never the destination.
It became the ecosystem where Antonio could continue learning, sharing, and evolving as a professional.

Maybe that's what makes the Atlassian Community so special.
There’s always someone willing to help you learn.

And there is always something new to learn.

I have a feeling this story isn't over.

I'm sure that, somewhere down the road, we'll have another conversation.

Somehow, I don’t think this will be our last conversation.

Claudia

How do you keep PRs from sitting for days on Bitbucket Cloud?

zoltanersek _outpostlabs_dev_ — Sun, 05 Jul 2026 12:23:18 GMT

One of the most common issues with PR is they are stuck in review. Sometimes it takes 3 or 4 days before someone takes a look at them.

There is no way to see, like a dashboard of who's waiting, who's reviewing etc.

I'm curious how other teams handle this. Do you use anything that nudges people and tracks review turnaround? Maybe native bitbucket notifications, a slack bot(ReviewNudgeBot or Axolo), an analytics tool or manual poking people? What actually worked for you? What didn't?

Unable to see my old boards using my same gmail ID i used to create atlassian account

Gurudatt — Sun, 05 Jul 2026 12:13:07 GMT

Unable to see my old boards using my same gmail ID i used to create atlassian account, Now in Atlassian it treats as a new account and i have lost all the boards i have created in Trello earlier. Any possible solution to recover all my boards Since i havent changed the email ID

dev-status API no longer returns commits on tickets

Alaa Humaidat — Sun, 05 Jul 2026 13:43:48 GMT

The following request returns an empty details array with http status 200:

[~]>curl -w "%{http_code}" -u "$USER:$TOKEN" -H "Content-Type: application/json" "https://atypon.atlassian.net/rest/dev-status/latest/issue/detail?issueId=1728410&applicationType=GitHub&dataType=repository" 
{"errors":[],"detail":[]}200

instead of the expected development info for Jira Cloud issues.

Has the endpoint been replaced or deprecated? If so, any other API to replace it?

How do I create a document creation plan in Jira?

Dulari Vikas Pawar — Sun, 05 Jul 2026 09:55:17 GMT

I want to create a Detailed Product Requirements Plan.

How do I do it using Jira?

What's the ideal length of a standup?

zoltanersek _outpostlabs_dev_ — Sun, 05 Jul 2026 09:38:44 GMT

I was part of many teams over the length of my career, and I keep finding 2 extremes when it comes to standups: they either last under 10 minutes or they go on for almost an hours. It's no surprise to anyone, that I prefer the first.

Now, what do you think an ideal standup should take?
What is your advice for optimizing long standups? Especially, what I can do as a relatively new member of the team.

We don't have a scrum master or someone 100% focused on agile practices.

Quick Check: What does a clean "Viewer-only" dashboard UI look like?

Bananake — Sun, 05 Jul 2026 07:22:32 GMT

Hi everyone,

We are currently building out an internal dashboard layout in Atlassian Analytics and are trying to optimise the UI experience for our standard "Viewer" group.

Could an Enterprise workspace admin kindly share a quick screenshot of what the top right/sidebar menu looks like for a user who has strictly "Can View" access?

We just want to see how much of the settings panel/sidebar options are hidden or streamlined for basic viewers so we can design our dashboard titles and documentation to match.

(Please feel free to blur or block out any actual data or chart contents, we just need to see the general navigation/header layout if possible!)

Thanks a bunch!

Why "18 of 20 done" doesn't always mean a release is ready

Steve Gilliard — Sat, 04 Jul 2026 20:12:07 GMT

Full disclosure: I'm with SG Development, the team behind Release Scheduler for Jira.

We kept running into the same conversation before every release: someone pulls up the fix-version board, sees 18 of 20 issues in Done, and calls the release "basically ready." Then release day arrives and it turns out one of those two open tickets was a P1 bug, another was blocked on a dependency nobody flagged, and a third ticket that looked done was actually still sitting in Backlog with a resolution someone forgot to clear. The board looked green. The release wasn't.

Percent-complete is a completion metric, not a risk metric. It doesn't know that one open bug is a blocker and another is a typo fix. It doesn't know two tickets are stuck behind an unresolved cross-team dependency. It doesn't know a ticket is still in QA vs. already through UAT vs. done. It just counts statuses.

That's the problem we've been chewing on in Release Scheduler: instead of one "% done" number, we compute a readiness score from several independent signals — actual completion, unresolved bug severity, blocking/blocked dependencies (including circular ones), schedule load vs. time remaining, and how far tickets have progressed through QA/UAT/Done rather than just whether any ticket reached Done. A release with three tickets stuck in Backlog scores differently than one where those same three are sailing through UAT — even though a naive "done/total" count would treat them the same.

It's still an imperfect model — we've had to go back and tighten it more than once as we found cases where it was too generous — but it's been a much more honest conversation starter with release owners than "are we green yet?"

Curious how other teams handle this: do you track anything beyond ticket status to judge release readiness (dependency risk, QA/UAT progression, schedule burn-down), or is "% done" still the main signal your team looks at?

Steve

My email account was blocked, and because of that I lost access to my previous Jira account.

luan cerqueira — Sat, 04 Jul 2026 18:06:42 GMT

Hello,

My email account was blocked, and because of that I lost access to my previous Jira account.

I'm trying to recover my Jira account, but the recovery process asks for my Jira site URL (mysitename.atlassian.net). However, when I enter the URL, it says that the site doesn't exist.

Could you please help me recover my account? This is urgent, as I need access as soon as possible.

Thank you in advance.

From SHV to Hiera: Bringing Above-Epic Hierarchy and Capacity Planning to Jira Standard

Germán Morales _ Hiera — Sat, 04 Jul 2026 16:43:59 GMT

Hey everyone!

A few months ago, I posted here looking for feedback on a Forge app I was building to solve a specific pain point: visualizing work above Epics without having to upgrade to Jira Premium. The feedback was incredibly helpful (thanks to everyone who reached out!).

Back then, it was called Strategic Hierarchy View (SHV). Quite a mouthful. Since then, the app has grown from a simple hierarchy viewer into a full planning workspace. So, to keep things simple, SHV is now officially Hiera.

Along with the new name, I’ve just shipped an update that addresses the two biggest headaches I hear from Jira Standard teams: Strategic Parents and Capacity Planning. Here is how they work and why I built them.

The "Jira Premium Gate" is Real

We’ve all seen this story play out: A team grows, and suddenly you need a layer above Epics (like Initiatives or Themes) to track company goals.

In native Jira Cloud, the official answer is: "Upgrade to Premium to get Advanced Roadmaps." But if all you need is a 3-level hierarchy and a simple timeline, upgrading a 50-user team just for that is a budget-killer. So what do teams do instead? They build a massive Excel sheet that gets out of sync in five minutes.

Hiera is my attempt to build a lightweight, native alternative that lives entirely inside Jira Standard.

1. Hierarchies Above Epic (Without Native Link Mess)

You can now map levels like Theme ➔ Initiative ➔ Epic ➔ Story directly in Jira Standard.

Keep your native links clean: Hiera stores these strategic relationships in Forge’s Key-Value Storage, so you don't have to mess up your native issue linking structure.
Native JQL Search: I mirrored these custom parents to a Jira issue property (hieraParent). This means you can still run JQL queries like hieraParent = "PROJ-123" to find all stories under a specific initiative.

2. The "Excel Killer": Cross-Project Capacity

Another major reason teams go back to spreadsheets is tracking who is doing what across multiple projects. I added three new tabs directly to the global view to solve this:

Capacity Heatmap (Auto): A zero-setup grid that scans your projects and highlights who is overloaded each week. Click any cell to see the exact issues causing the bottleneck.
Workload Matrix (Manual): A simple spreadsheet-like grid where developers can declare the hours they expect to spend on each project. It auto-saves as they type.
Team Aggregate: A single table for admins to spot overallocated team members and adjust their weekly hours in one click.

Built Solo on Forge

Since the app is built on Atlassian Forge, all data stays securely within Confluence and Jira. As a solo dev, I don't have a sales team or prioritization meetings—if you tell me a feature is missing or a bug is blocking you, I usually have the fix live in production in less than 24 hours.

I’d love to get your honest thoughts:

If you're on Jira Standard, how are you currently tracking work above Epics? Are you still stuck in Excel?
What’s the one feature you wish Jira Standard had out of the box for team capacity?

Let's chat in the comments! If you want to check it out, Hiera is available on the Atlassian Marketplace.

Bitbucket's Journey: History, Gaps, Opportunity and Road Ahead

Viswanathan Ramachandran — Sat, 04 Jul 2026 13:37:16 GMT

Bitbucket: from small startup to Atlassian’s code collaboration engine

History

Bitbucket started with a simple idea: give developers a place to host code and collaborate without friction. It was founded by Jesper Nøhr in 2008 as an independent startup, then acquired by Atlassian in 2010, which gave it the backing of a much larger platform company.

After the acquisition, Bitbucket evolved from a repository host into a deeper part of Atlassian’s product family. Atlassian pushed it toward tighter integration with Jira, build automation, access controls, and cloud delivery, so that teams could move from issue tracking to pull requests to deployment with fewer handoffs.

That positioning has always been Bitbucket’s strength. For teams already living in Jira and Atlassian workflows, Bitbucket feels less like a standalone Git tool and more like the code layer of a connected delivery system.

Why it can feel behind

Bitbucket can feel behind close competitor because that competitor is often seen as a more complete, all-in-one DevOps platform, while Bitbucket is more narrowly centered on source control and CI/CD inside the Atlassian stack. The competitor markets itself as a single platform for planning, building, securing, and monitoring software, while Bitbucket’s messaging emphasizes code collaboration, Jira integration, and pipelines.

Another reason is product momentum. Atlassian has been publicly leaning hard into cloud growth, AI, and enterprise sales, which suggests Bitbucket is part of a larger platform strategy rather than the single hero product.

Investment view

Is Atlassian making Bitbucket Cloud worth betting on?, the answer is a cautious yes for enterprise-oriented buyers, and a more mixed answer for startups or teams that want the deepest all-in-one DevOps suite. Atlassian is clearly investing in cloud, AI, and enterprise workflows, and Bitbucket Cloud now includes AI features, CI/CD, security controls, and a free tier for small teams.

The risk is that Bitbucket is competing in a market where the competitor often has the clearer platform story. The opportunity is that Atlassian already owns a huge amount of adjacent workflow context through Jira, Confluence, and Jira Service Management, which makes Bitbucket strategically valuable even if it is not always the loudest standalone Git product.

Does organisations are moving from Bitbucket?

It’s less about replacing Git repositories and more about simplifying the DevSecOps ecosystem.

The main drivers are:

Integrated DevSecOps – Built-in SAST, DAST, dependency, secret, and container scanning.
Platform consolidation – Source control, CI/CD, security, package registry, and governance in one place.
Stronger governance & compliance – Audit trails, approval policies, protected branches, and compliance frameworks for regulated environments.
Scalable CI/CD – Better support for enterprise pipelines, self-hosted runners, and deployment controls.
Lower operational complexity – Fewer third-party integrations to maintain.

That said, Bitbucket remains a strong choice for organisations already invested in the Atlassian ecosystem with mature CI/CD and security tooling.

The shift isn’t simply Bitbucket vs someone it’s about moving from a collection of tools to a unified DevSecOps platform that improves security, governance, and developer experience.

How Bitbucket can close the gap

Bitbucket can improve by turning its integration advantage into a more obvious platform advantage. The fastest path is to make the journey from Jira issue to pull request to pipeline to release feel seamless, visible, and measurable for engineering leaders.

It should also deepen native DevSecOps and analytics, because modern teams want security, auditability, and delivery insights without stitching together too many tools. Atlassian has already been adding AI, CI/CD, and premium controls, so the next step is to make those capabilities feel more central and less optional.

Another important move is better developer experience. If Bitbucket wants to win hearts, it has to be fast, intuitive, and opinionated enough that teams do not feel they need to leave the Atlassian stack to get a modern workflow.

Road Ahead

Bitbucket’s future will be decided not by whether it copies the competitor, but by whether it can make Atlassian workflows feel like the most natural place to build software.

Looking what others feel about Bitbucket? Curious to hear. What has been the biggest driver?

Regards

Viswa

How to get a License Key

Hemanth Yadav — Sat, 04 Jul 2026 09:36:06 GMT

I bought a JIRA software for my company from my Laptop. I need to provide Licencekey to my company support team to install JIRA software on our company server.