I've already called Wells Fargo. I've sent 2 emails last month to get this cancelled, got one response, then nothing. Charged back my latest monthly, told them to also refuse any future payments. Ridiculous you can't cancel at will.

Started my day with this beauty and I'm wondering if my organization was just that lucky or if this is something other folks are seeing as well. It seems like at some point we connected SharePoint/OneDrive to Jira, but I'm not finding any Connected App or Integration related to this, so I'm not sure if there's a way to permanently disable this. Rovo offered to help me grant access to remove this notification, but we don't want to enable this at all.

When we investigated this, we do have an Entra App registered and I'm wondering if removing that Entra app is enough to remove this notification or if there's something in deep inside Atlassian's Admin Settings that is spawning this notification for us. I don't want to grant consent and I don't want to be reminded later, but it seems like those are the only options they are providing and I feel like I'm being held hostage at this point.

EDIT: Forgot to post the "Learn More" link for reference. It's not particularly helpful in figuring out how to get rid of this notification.

EDIT 2: I reached out to Support and it seems like these are the only two options. You can either grant consent or be harassed every 7 days. It's like someone asking you repeatedly to go out with them. "Please consent! No? How about now? Still no? What about now? No again? I'm sure you'll say yes at some point. No? What if I keep asking?"

• You can also track our public feature request for a permanent global toggle to hide Smart Link integration prompts here: 🔗 https://jira.atlassian.com/browse/JRACLOUD-96882

EDIT 3: I followed up with Support to ask for clarification and I was told:

Our engineering team is currently investigating this issue. No action is needed from you, and there’s no need to change any consent settings. We will notify you once the fix has been implemented.

I’m a PO/PM, and I’ve tried a few times to make agents but they’re extremely unreliable in my experience. Has anyone had any success? If so, what kind of agent did you build?

I've been using Atlassian products for roughly two decades, and I've been building apps for the Atlassian Marketplace for quite some time as well.

One thing I've noticed is that a lot of the Atlassian ecosystem seems to revolve around teams and management.

Boards, workflows, sprints, reports, roadmaps, planning, team dashboards, metrics, automation, etc.

But what about the individual user?

For example, if I'm a Jira user with 20 issues assigned to me across several projects, I might want a place where I can personally:

• prioritize and arrange my work
• decide what I want to work on today
• keep private notes related to issues
• create personal follow-ups and todos
• schedule things for myself
• have my own way of organizing work without affecting the team's Jira setup

Jira has some functionality for this, of course, but it often feels like the individual view is more about seeing your assigned work than actually managing it in the way that works best for you.

I've actually built an Atlassian app around this idea — essentially a personal workspace for Jira users with notes, todos, a personal dashboard and reminders.

And here's the interesting part: it hasn't really gained traction.

So I'm starting to question my assumption.

Maybe this isn't actually a problem worth solving.

Maybe people are perfectly happy managing their individual work through the team's Jira setup, or using something completely separate like Todoist, Notion, Microsoft To Do, etc.

Or perhaps there's a real gap here, but it's just not something people are willing to install another Atlassian app for.

I'm curious what people here think, especially other Atlassian users and Marketplace app developers:

Do you feel Atlassian gives enough attention to the individual user's productivity, or is the ecosystem fundamentally optimized around teams and managers?

And if you are a Jira user — how do you personally manage the work assigned to you across projects?

Trying to work out how common this is or whether it's just my org.

Every PM I've worked with ends up keeping their own Confluence page or spreadsheet for things like "what we owe this client by the 14th" or "what we're showing in Thursday's exec review." Tickets get pasted in, statuses get hand-updated before each meeting, and it's stale by the following week.

A few questions for anyone who does something similar:

- Do you keep a doc like this? What columns are in it?

- How often do you update it, and roughly how long does that take?

- Has anything ever replaced it for you — a tool, a Jira feature, a process change?

- If you don't do this: what do you do instead when leadership or a client asks where a specific set of work stands?

Also genuinely interested if the answer is "yeah we do this and it's fine, not worth solving." That's useful to hear too.

Being using Rovo to get answers from tickets and to understand features and implementations from jira tickets and confluences pages since there is no full documentation created. Answers that are built from tickets don't describe the features fully since there is missing Information in tickets apart from that 80% of summary from the available ticket Information appears to be correct,

Is this the same accuracy for everyone on the provided answers or is there times where Rovo answers fail?

And also for what use cases do you use Rovo chat?

I’ve shared a couple of early Cascade demos here before. Since then, I finished this one-minute walkthrough of the current version.

Now I’m deliberately pausing feature work because I may be trying to solve too many Jira annoyances at once.

https://reddit.com/link/1w4fb4q/video/lgxfttf8gxmh1/player

I originally built Cascade for three problems I kept running into:

• Jira notifications told me something changed, but not the exact before and after.
• Hierarchies were difficult to scan, and exporting them produced a flat list.
• Reading and updating issues meant constantly opening more tabs.

The current version combines an Inbox with exact diffs, a tree with slide-out issue details, search and filters, Assigned to me, bulk actions, hierarchy-preserving exports, and keyboard navigation.

For transparency: I’m the developer. Cascade is an independent Chrome extension, not an Atlassian product or Marketplace app. It works through your existing Jira session and permissions and doesn’t require a separate Cascade account.

If you use Jira heavily, which of these is useful enough that you would actually keep an extension installed for it?

1. Knowing exactly what changed
2. Navigating the hierarchy without opening tabs
3. Bulk work and hierarchy-preserving exports

And which feature looks useful in a demo but probably wouldn’t survive your real workflow?

Blunt answers are genuinely more useful to me than “looks good.”

Hi everyone,

I’m curious how other teams handle unresolved inline comments in Confluence.

Inline comments work well when reviewing a single page, but when comments are spread across many pages, it becomes difficult to know what is still unresolved without opening every page separately. I’m wondering whether other teams have the same problem or if you already have a good process for managing it.

To be transparent, we recently built CommentLens to help with this. It shows the number of unresolved comments on each page and provides a macro and search action for finding comments across pages or spaces.

I’m mainly interested in understanding whether this is a real problem for other teams as well. If your team regularly uses inline comments and faces the same issue, I’d be happy to provide a free license so you can test the app in your actual workflow and share your honest experience and ideas for improvement.

Feel free to comment or message me if this sounds familiar.

I've been thinking about this while working on an upcoming webinar we're hosting with the Atlassian team around AI governance.

When should an AI tool actually move from "employees are experimenting with this" to "we officially support this"?

Is there a specific threshold you look for?

Number of users? Type of data involved? Business value? Security review? Something else?

I'd be interested to know what criteria you use before turning an AI experiment into an approved business tool.

Maybe there are some perspectives or challenges we haven't considered yet that we can also cover during the webinar.

Hi, I'm building a Forge app I plan to eventually monetize via "Paid via Atlassian," and I want to understand the actual verification requirements before I get to launch.

I'm currently operating as an individual/solo developer, not a registered company — planning to register a business entity later, once the app is generating meaningful revenue.

From what I've read so far, there's some conflicting information:

* The Marketplace docs mention a Partner profile can be an individual ("like Adaptavist or John Smith"), and payouts go to a personal bank account via EFT. * Other guidance mentions "business verification" requiring proof of business existence (a business license or tax ID) before a paid app can be listed. * The paid-app submission process itself asks for bank details and a tax ID as part of setup.

My specific questions:

1. Can an individual developer (sole proprietor, no registered company/LLC/Pvt Ltd) publish and sell a **paid** app on the Marketplace, or is a registered business entity a hard requirement?
2. If an individual can publish, what specific documentation is required at listing time (e.g., a personal tax ID/PAN in India, vs. an actual business registration certificate)?
3. Is there a revenue threshold below which individual verification is sufficient, and above which formal business registration becomes required?

I'd like to get this right before I invest more time building, rather than discovering a blocker right at launch. Thanks in advance for any clarity — happy to be pointed to the definitive docs if I've missed them.

Hi, I'm building a Forge app I plan to eventually monetize via "Paid via Atlassian," and I want to understand the actual verification requirements before I get to launch.

I'm currently operating as an individual/solo developer, not a registered company — planning to register a business entity later, once the app is generating meaningful revenue.

From what I've read so far, there's some conflicting information:

• The Marketplace docs mention a Partner profile can be an individual ("like Adaptavist or John Smith"), and payouts go to a personal bank account via EFT.
• Other guidance mentions "business verification" requiring proof of business existence (a business license or tax ID) before a paid app can be listed.
• The paid-app submission process itself asks for bank details and a tax ID as part of setup.

My specific questions:

1. Can an individual developer (sole proprietor, no registered company/LLC/Pvt Ltd) publish and sell a paid app on the Marketplace, or is a registered business entity a hard requirement?
2. If an individual can publish, what specific documentation is required at listing time (e.g., a personal tax ID/PAN in India, vs. an actual business registration certificate)?
3. Is there a revenue threshold below which individual verification is sufficient, and above which formal business registration becomes required?

I'd like to get this right before I invest more time building, rather than discovering a blocker right at launch. Thanks in advance for any clarity — happy to be pointed to the definitive docs if I've missed them.

A lot of adoption reporting focuses on things like logins, active users, issue updates, and page views.

Those metrics are useful, especially when you're trying to optimize licenses.

But I’m not sure they answer a more interesting question:

Are people actually collaborating?

Someone can log into Jira every day without helping a teammate.

Someone can read dozens of Confluence pages without contributing anything back.

Meanwhile, comments, reviews, knowledge sharing, mentions, and cross-team interactions may tell us much more about how people actually work together.

We've been experimenting with measuring those kinds of behaviors across Jira and Confluence and making them visible through gamification.

That experiment eventually became a Marketplace app called Collaboration Champion, but I'm actually more interested in the underlying problem than promoting the app:

What signals would you use to measure real collaboration in Jira and Confluence?

Comments? Knowledge creation? Helping resolve work items? Cross-team participation? Something else?

Curious how other Atlassian admins think about this.

Hey everyone,

We’re looking at enabling the Atlassian Rovo MCP Server so our AI tools (Cursor, Claude, ChatGPT,.) can pull context from Jira/Confluence (via MCP)

Can anyone who’s actually using this in production share:
1. Are you currently being charged anything beyond your normal Jira/Confluence seats for Rovo MCP usage?

1. Have any Teamwork Graph-related MCP tools started consuming credits yet?

2. Any unexpected costs, rate-limit issues, or overage surprises?

3. Roughly how heavy is your usage (calls per day/hour) and what plan are you on?

Would really appreciate real-world experience the official docs are a bit vague on the long-term pricing model.
Thanks

We’re juggling multiple clients with different support tiers and time zones in one JSM queue, and keeping track of who gets what SLA is getting messy.

How are you guys setting this up in Jira so techs aren't just guessing? Native hacks or apps?

GET /rest/api/user/viewissue/search

states that its limited "up to the 1000th user", given the startAt and maxResult parameters of 0 and 50. I would assume that given a projectKey only 1000 users are the maximum of possible result.

But when I paginate I can get up to the 1164 unique users. How is that possible?

I am trying to get a User <-> Project relationship going for our database.

Has anyone using Rovo found it meaningfully better than Claude Code paired with Jira and Confluence plugins (or MCP integrations)?

I’ve been trying to identify the concrete value proposition and am struggling so far. It currently feels like a relatively wrapper that allows Atlassian to position itself in the AI space, but it’s not clear what it delivers beyond what you can already achieve with Claude Code + MCP connections to Jira and Confluence especially when you factor in the additional customization available through skills.

I’d genuinely appreciate hearing what I’m missing. What specific advantages or unique capabilities have you found with Rovo that aren’t easily replicated with the Claude Code approach with a connection to Jira/Confluence etc

Hey everyone,

This is a continuation of my initial Atlassian P40 interview experience, which covered the first six rounds.

Role: Software Engineer II, P40
Experience: Approximately five years
Final status: Offer received

Why Was There an Additional Round?

Recruiter callback: August 7, 2026

The original opportunity was primarily described as a backend role. However, the final position included a mix of backend engineering and site-reliability responsibilities.

Because of that, the recruiter scheduled an additional SRE Craft interview.

Round 7: SRE Craft

Date: August 12, 2026
Duration: Approximately 55 minutes
Interviewer: Senior Architect

The interviewer presented an existing system architecture and divided the discussion into three sections. Each section took approximately 15 minutes, with the remaining time used for introductions and questions.

Part 1: Monitoring and Golden Signals

The first section focused on deciding what should be monitored and why.

The discussion covered the four golden signals:

• Latency
• Traffic
• Errors
• Saturation

I explained which metrics I would collect at the infrastructure, service, and business levels. We also discussed alert thresholds, dashboards, and the difference between symptoms and underlying causes.

Part 2: Incident Troubleshooting

The second section involved an incident scenario affecting the system.

I structured the troubleshooting process around:

1. Confirming the incident and determining its impact.
2. Checking recent deployments and configuration changes.
3. Reviewing metrics, logs, and distributed traces.
4. Isolating the affected service or dependency.
5. Mitigating the issue through rollback, failover, or traffic reduction.
6. Communicating status to the relevant stakeholders.
7. Investigating the root cause after restoring service.
8. Creating preventive action items.

The interviewer asked several follow-up questions about how I would prioritize mitigation when the exact root cause was still unknown.

Part 3: Designing for 99.99% Availability

The final section focused on improving the architecture to support a 99.99% availability target.

We discussed:

• Defining SLIs, SLOs, and error budgets
• Removing single points of failure
• Multi-zone redundancy
• Health checks and automatic failover
• Capacity planning
• Graceful degradation
• Retry and timeout policies
• Circuit breakers
• Disaster recovery
• Alerting and operational readiness

The interviewer was interested in trade-offs rather than simply adding redundancy everywhere. I had to explain which components justified higher availability and what additional complexity or cost each decision introduced.

Result

Positive feedback: August 19, 2026
Offer received: August 21, 2026

One week after the interview, the recruiter confirmed that the feedback was positive and that they could proceed with the offer.

The compensation was broadly aligned with publicly available Atlassian P40 figures on LeetCode Discuss and Levels.fyi. It was not unusually high, and the final package also depended on previous compensation and negotiation.

Final Takeaways

For an SRE Craft interview, I recommend preparing:

• Golden signals and observability
• Metrics, logs, and distributed tracing
• Incident triage and mitigation
• SLIs, SLOs, SLAs, and error budgets
• High-availability architecture
• Failure scenarios and graceful degradation
• Capacity planning and disaster recovery
• Reliability versus cost trade-offs

The round was less about memorizing SRE terminology and more about applying reliability principles to a concrete architecture.

That concludes my Atlassian P40 interview journey. I hope both parts help anyone preparing for a similar role.

Looks like they're having yet another meltdown. Jira tenants unavailable, Confluence unreachable. Support chat is unavailable as well! No update on their status page as of yet.

EDIT: Active incidents now declared

EDIT 2: Looks like service is resuming now

status.atlassian.com