Atlassian

How Wendy’s turned everyday challenges into enterprise-wide transformation The learnings in this blog post are based on the session “Wendy’s recipe for launching faster with Atlassian” from Atlassian’s Team ’26 conference. Watch this session on demand. Prior to adopting a unified enterprise platform, the nationwide restaurant chain Wendy’s operated in a fragmented manner. Teams were managing their own tool subscriptions, duplicating efforts, and relying on inconsistent processes, spreadsheets, and disconnected data. Without a unified strategy or governed source of truth, it was hard to see work clearly, report on progress, support audits, or scale better ways of working across IT and business teams. That is why Wendy’s chose Atlassian as its platform for scaling. The team needed more than another project tracker; they needed a connected system that could support work management, portfolio governance, knowledge sharing, service workflows, assets, analytics, and automation without forcing every team into the same rigid process. Wendy’s Atlassian Administrator Deven Gambrell and Portfolio Manager of Technology Initiatives Emery Jordan shared how their two-person team helped grow Wendy’s Atlassian footprint from 147 users to nearly 1,000 active users in less than two years. Gambrell brings nearly a decade of Atlassian administration experience across both data center and cloud environments. Jordan has spent over 20 years in the program, project, and portfolio management space across multiple industries. Together, they are the entire Atlassian team at Wendy’s, and the growth they drove was powered by change management, relationship-building, and practical solutions delivered across the business. From focused IT adoption to enterprise-wide impact When Wendy’s began this journey, the company’s Atlassian footprints had pockets of usage, but it was not yet positioned as the central enterprise platform. Over time, that changed dramatically. What made Atlassian the right platform was not a top-down mandate. It was the combination of enterprise govern...

Atlassian named a Strong Performer in The Forrester Wave™: Strategic Portfolio Management Tools, Q2 2026

Cloud Fortified availability checks ambiguity during Connect to Forge Remote migration Hi Atlassian team, We migrated an existing Connect Marketplace app to Forge using Forge Remote, and we’re trying to understand how Cloud Fortified availability monitoring behaves during and after this transition. Our app previously had a Connect descriptor at: /atlassian-connect.json In the Forge version, we now define remote backends in manifest.yml using remotes.baseUrl, including region-specific URLs for data residency. During a recent backend deployment, we observed short-lived 502 responses in our server logs for requests with: User-Agent: Atlassian-CFA-healthcheck Path: /atlassian-connect.json This appears to have correlated with Cloud Fortified availability alerts. However, Forge apps do not use atlassian-connect.json as their descriptor, so we’re unsure whether this alert is coming from: A legacy Connect healthcheck still configured for the Marketplace app/version. A healthcheck for older Connect versions that still have active installations. A Cloud Fortified check that remains tied to the app’s historical Connect descriptor even after migration. Something related to Forge Remote availability monitoring, though the path suggests Connect. The documentation and forum posts seem to leave this unclear: CHANGE-775 says app base URLs and regions are monitored for Cloud Fortified availability. The Forge Cloud Fortified announcement says Forge reliability is handled differently, using invocation success rates and latency. Forge Remote introduces partner-hosted backend URLs, but we could not find a clear statement on whether Cloud Fortified probes Forge Remote remotes.baseUrl endpoints directly, or what SLI/SLO applies to those remotes. Could Atlassian clarify the following? For apps migrated from Connect to Forge/Forge Remote, does Cloud Fortified continue to monitor the old Connect healthcheck path? If older Connect versions still have installations, are their base URLs and healthcheck paths still monitored independently? Are Forge Remote remotes.baseUrl values di...

RFC-137: Forge App Suspension Behaviour RFCs are a way for Atlassian to share what we’re working on with our valued developer community. It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early. Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks! Project Summary This RFC defines how Forge app installations behave when they enter a suspended state. We want to give you - as a Forge developer - a clear, predictable contract: what happens to your app’s functions, UI extensions, product events, and storage access during suspension, and what you should do to handle the transition cleanly when your app comes back online. Publish : 05 June 2026 Discuss : 19 June 2026 Resolve : 03 July 2026 Problem Your Forge app can enter a suspended state for a number of reasons - for example, when a customer’s Marketplace subscription lapses, when data is being migrated to a new region, or when Atlassian needs to take an app offline for operational reasons. Today, what actually happens to your app during suspension is not consistent: Your app may continue to appear available in some places while silently failing in others (e.g. invocations blocked). This creates a confusing experience for both, you and your customers. There is no documented, reliable contract for what you can expect during suspension - whether your functions will be called, whether your UI extensions will render, whether product events will be delivered, or whether your storage will be accessible. This also means that when ...

Prevent container image overwrites with immutable tags in Bitbucket Packages

Stop counting who uses AI. Start finding who’s transforming with it.

Advancing modern teamwork AI thinking and product news to unleash the potential of teams

Atlassian named a Strong Performer in The Forrester Wave™: Strategic Portfolio Management Tools, Q2 2026 We improved across the board — and our Vision and Innovation scores tell a bigger story about where SPM is heading. We’re proud to share that Atlassian has been recognized as a Strong Performer in The Forrester Wave : Strategic Portfolio Management Tools, Q2 2026 . But the placement is only part of the story. We have evolved since 2024. In this recent evaluation, we received a Current Offering score of 3.10 and a Strategy score of 3.80, reflecting our continued investment in delivering comprehensive strategic portfolio management capabilities. Our scores reflect something we’ve been building deliberately: a point of view on where Strategic Portfolio Management (SPM) needs to go and the investment to get there with Atlassian’s Strategy Collection . And that point of view was validated with the highest possible score: 5 out of 5 on Vision and Innovation. From signal to action: what’s still broken in enterprise decision-making In our latest whitepaper Leading the Human + AI Enterprise , we surveyed 308 senior leaders and found a stark gap: 80% say their priorities are clear , but only 11% have their portfolio work connected to those priorities in a shared system. Fewer than one in three can act on a strategic change within a week. We call this mean time to pivot , and in most enterprises it’s measured in months, not days. AI doesn’t solve this. Our research found that the biggest factor in AI effectiveness is domain connectivity (whether strategy, work, and execution data exist in a connected model), more than any other factor. Fragmented operating models don’t just slow you down. They make AI more expensive to run and less valuable to the business. What Forrester recognized and what it signals Forrester’s vendor profile describes Atlassian as having “an AI-powered model with a connected work graph to break down organizational silos, deliver on strategic outcomes, and balance capacity and costs” and calls that vision “well in line with SPM’s expanded focus.” Our point ...

Prevent container image overwrites with immutable tags in Bitbucket Packages We’re excited to announce that immutable tags are now available for the Bitbucket Packages container registry . With immutable tags, workspace admins can set container image tags from being overwritten, moved, or modified after they’re first pushed. Tags are how your team refers to container images, but by default they’re mutable: anyone with push access can point an existing tag at a different version of the image. For a tag like v1.2.0 or prod, that means the image running in production today might not be the one you tested and approved yesterday. Immutable tags remove that uncertainty. Once a tag is locked, it points to the same image every time, so your releases stay reproducible, your deployments stay predictable, and you have the audit trail you need to meet compliance requirements. Benefits of immutable tags Improve reproducibility : A locked tag always points to the same image digest, so the image you tested is the image you deploy. Reduce deployment risk : Immutable production and release tags can’t be silently overwritten. Support compliance : Immutable release tags help teams meet audit and compliance requirements. How immutable tags work Immutable tags is configured at the workspace level from the Container settings page. You’ll choose from three options: No tags are protected : All tags stay mutable. This is the default. All tags are protected : Every tag becomes immutable after it’s first pushed. Some tags are protected : Only tags matching custom rules become immutable. When you choose Some tags are protected , you can create up to 7 custom rules per workspace. Each rule uses a rule name and an RE2 regular expression pattern of up to 100 characters, evaluated against the tag name being pushed. A built-in pattern tester lets you check a sample tag before you save. Here are a few examples: Goal Example pattern What it matches Protect a production tag ^prod$ Only the tag prod Protect semantic version tags ^v\d+\.\d+\.\d+$ Tags like v1.0.0 or v2.14.3 Prot...

How switching to Jira Service Management and Rovo helped Neta cut ticket escalations by 35% Ever wondered what’s possible when you connect service management, knowledge, and AI on a single platform? Meet Neta , the proprietary software platform for energy and utilities of Engineering Group (ENG) ENG is a global Digital Transformation Company with more than 14,000 employees across 50+ subsidiaries in 21 countries. Neta is supported by a dedicated team of around 700 professionals across Italy, Spain, and Brazil, delivering a modular platform for energy and utility providers that covers the entire “meter-to-cash” lifecycle, from CRM and billing to metering, ERP, and workforce management. They also provide Application Management Services (AMS), and the AMS team ensures business continuity and user support to a mission-critical platform for Utilities, combining application governance, domain expertise, and structured operational capabilities. The problem: too many escalations and siloed knowledge Before Jira Service Management, Neta’s AMS team was running on an older version of BMC Remedy. It worked, but it wasn’t built for what they needed next. The team needed a new approach with an effective, innovative tool that made AI an essential component for the evolution of service. The challenge Neta faced was familiar to a lot of support organizations: junior agents couldn’t handle complex tickets on their own. They’d need to pull in an already busy senior product expert. Knowledge lived in silos, scattered across teams and tools, and finding the right documentation to resolve a ticket ate up time that nobody had. “Our vision was simple,” Grazia Maria Zucca, Head of Application Management Services, told us. “Anyone in the AMS team — even at the junior level — should be empowered to be a product expert. That’s what we set out to build.” Connecting Jira, Confluence, and Jira Service Management Neta was already using Jira and Confluence for development and documentation. When they started exploring AI capabilities inside the platform — especially Atlassian Rovo agents ...

Forge external auth completes successfully, but outboundAuth/finish tab does not close and UI shows “auth window closed” Forge external auth completes successfully, but outboundAuth/finish tab does not close and UI shows “auth window closed” Hi, I’m seeing an issue with Forge external authentication and I’d like to know whether anyone else has run into something similar. I have a Forge Jira issue panel using an OAuth2 provider configured against Microsoft Entra ID. The app requests an access token for my own backend API, not Microsoft Graph. The provider is configured roughly like this: providers: auth: - key: microsoft-backend name: Microsoft Backend type: oauth2 clientId: scopes: - openid - profile - email - api:// /access_as_user remotes: - portal-backend bearerMethod: authorization-header actions: authorization: remote: microsoft-login path: / /oauth2/v2.0/authorize exchange: remote: microsoft-login path: / /oauth2/v2.0/token refreshToken: remote: microsoft-login path: / /oauth2/v2.0/token retrieveProfile: remote: portal-backend path: /api/auth/profile resolvers: id: id displayName: displayName remotes: - key: microsoft-login baseUrl: https://login.microsoftonline.com - key: portal-backend baseUrl: https:// My backend validates the Microsoft JWT using Microsoft JWKS and checks: signature exp / nbf / iat aud = api:// tid / issuer scp contains access_as_user The retrieveProfile endpoint is intentionally simple. Forge calls it with the bearer token, my backend validates the token, extracts claims from it, and returns: { "id": " ", "displayName": " ", "email": " ", "tenantId": "...", "objectId": "..." } From the backend logs, everything looks successful: JWT valid aud=api:// scope=access_as_user GET /api/auth/profile [AUTH PROFILE] Returning Forge profile id=... displayName=... Also, if I manually refresh the Jira issue panel after the auth flow, the app correctly detects that the user is authenticated. So the credentials seem to be stored by Forge. The problem is that the auth browser window/tab remains stuck on: https://id.atlassian.com/outboundAuth/finish?code=...&state=... and the...

How to get attachments for a specific version of a page Hello, I’m trying to get the attachments of a page using the API. I’m using an API key, and to get a list of attachments i’m calling: https://{company}.atlassian.net/wiki/rest/api/content/{pageID}/child/attachment Once I get the attachment ID, I download it (this time using OAuth2 / 3LO) with https://api.atlassian.com/ex/confluence/{cloudID}/rest/api/content/{pageID}/child/attachment/{attachmentID}/download The results are correct. However, the first call returns all the attachments of all the versions of the page, not just the current version. For example, say the page has the following attachments Page version 1: Image1.jpg Image2.jpg Image3.jpg Image4.jpg Page version 2 (current): ImageAlbum.pdf (the images were deleted and merged into a single file) The results includes all 5 files. However, our app should see only the most recent one (in this case ImageAlbum.pdf). The attachment objects returned don’t have any mention of the version of the parent page where they are located, so I can’t filter them either. Is there a way to obtain the attachments of just the last version of a page using the API? Alternatively, with the ID of the page and the attachment, can I check if the attachment is present in the last version of the page? 1 post - 1 participant Read full topic

How Ace Hardware Modernized IT with Jira Service Management Modernizing for a second century in business with integrations, automations, and hard-won lessons from a 5,200-store rollout. The learnings in this blog post are based on a discussion with Ace Hardware presented at Atlassian’s Team ’26 conference . Ace Hardware is a 102-year-old hardware co-op that’s a staple across the US. When they decided to modernize their IT service management, they teamed up with Atlassian ITSM specialized solution partner Stratacom to roll out Jira Service Management across their entire IT operation. At Atlassian’s recent Team ’26 event, Jeff Nason, a 26-year veteran at Ace Hardware and team lead for production support, and Greg Guertin, Project Architect at Stratacom with 18 years of experience, walked through their full implementation journey. Explore the story behind what they built, how they brought it to life, and the lessons that can help other IT teams modernize with confidence. A co-op at scale Ace Hardware was established in 1924, named after the fighter pilots of World War I. It operates on a co-op model — meaning the stores actually own the corporate entity. Every investment, every tool decision, every budget line item has to serve the best interests of all store owners, from chains running more than 300 locations to the individual mom-and-pop shop on the corner. With the co-op model inevitably comes scale. Ace’s 12,000 corporate employees (excluding store staff) support 5,200 domestic stores across 15 warehouses, a presence in 60 countries with 3,000 international stores, and a distribution network so wide that 75 percent of Americans live within a 15-minute drive of an Ace location. That means the stakes are high for IT. When ITSM breaks down at a company this size, such as when tickets get lost, tools go dark, or teams can’t see what’s happening across applications and infrastructure, the ripple effects reach thousands of stores and millions of customers. Getting ITSM right isn’t just an internal efficiency play; it’s a business...

Premium self-hosted runners are generally available

Premium self-hosted runners are generally available In December, we shared our plans to introduce pricing for self-hosted runners. You told us loud and clear that a free option matters. Today, as Premium Runners become generally available, we are happy to share that we will continue to have a free tier, which includes the use of up to 100 self-hosted runners as part of your plan. If your team needs more scale, dedicated support, or advanced management features, you can upgrade to Premium Runners when you’re ready. If you’re already using our V5 paid runners, you will automatically be migrated to the Premium tier. All other versions will remain on the free tier and you can upgrade anytime. Premium runner capabilities Premium Runners are designed for teams that need more control over how CI/CD workflows are executed and managed. Here are the upgrades that you get with the Premium tier. Feature Free Runners Premium Runners Support Community Premium Support Runner per Workspace 100 1000 Custom storage Custom volumes for docker based runners Custom resources for docker based runners Advanced queue management Runner Groups (coming soon) Auto-update (coming soon) To upgrade, go to your Workspace settings > Pipelines > Workspace runners, and choose your tier. Note that to activate Premium runners, your Bitbucket workspace must be connected to an Atlassian organization for billing purposes. Pricing Premium self-hosted runners are billed at $15/month per concurrent build slot , which is the maximum number of builds that can run simultaneously across your workspace. Standard plans include one free slot, Premium includes two slots. To manage your budget, you can set your max slots in workspace settings; any concurrent builds beyond that limit will get queued until a slot frees up. You are only billed for the max concurrent slots that you actually use in the month. Billing example If you’re on the Premium Bitbucket plan and set a concurrency limit of 50 runners but only reach a max of 30 concurrent builds during the month, you wi...

In-house plugin issues compatible with jira 10.3.21 Our existing plugin is running on JIRA 9.12.30 without any problem. Recently, our jira upgraded to 10.3.21. So we need to upgrade the plugin to be compatible with jira 10.3.21. However , we ran into different build and compiling issues. The current build issue. It isn’t clear what version of dependency for com.atlassian.activeobjects is compatible with jira 10.3.21 so I can put the proper version of the dependency is the pom.xml. com.atlassian.activeobjects activeobjects-plugin 7.1.2 provided we also having below error during jira startup. 'gov.eop.omb.jira.vacms.MAX-JIRA-VACMS-Plugin' - '# JIRA VA Criteria Management System Plugin' failed to load. Cannot start plugin: gov.eop.omb.jira.vacms.MAX-JIRA-VACMS-Plugin Unable to resolve gov.eop.omb.jira.vacms.MAX-JIRA-VACMS-Plugin [197](R 197.0): missing requirement [gov.eop.omb.jira.vacms.MAX-JIRA-VACMS-Plugin [197](R 197.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.plugin.webresource)(version>=7.2.6)(version =7.2.6)(version VA Criteria Management System Plugin (v1.0.93) 1 post - 1 participant Read full topic

Create Custom field type view interface issue Hello, I am trying to define a new custom field type with the 3 interface, view, edit, contextConfig. I have followed the documentation and the examples here and I successfully create edit and contextConfig interfaces using custom ui, now I am facing the issue with the view interface, I tried both custom ui and ui kit but nothing is working, what I did understand is that the system always returns the formatter expression, not the resource, thank you for the help, kind regards, 2 posts - 2 participants Read full topic

How Loom turns customer support into a driver of business growth with Atlassian Customer Service Management Loom resolved over 80% of support inquiries with AI and reduced the likelihood of churn by 11% – transforming support into a growth driver. Key results After implementing Atlassian’s CSM and an embedded AI agent, Loom experienced: 80% AI resolution rate (without human support agent escalation) 11% less likely to churn +10.7% increase in video creation after launching in-product AI support widget Executive Summary Loom didn’t just improve support — they proved better experiences drive retention and growth. Challenge: Loom needed to scale support for millions of users without adding headcount, while reducing tickets and improving customer experience. Solution: Loom adopted Atlassian Customer Service Management (CSM) and embedded AI-powered, in-product support to move beyond ticket-based workflows. Impact: Loom transformed support into an AI-powered engine that reduces escalations, increases product engagement, and improves customer loyalty — turning support into a driver of customer value, not just a cost center. A fast-growing video messaging platform with a support model under pressure Loom, an Atlassian company and video communication platform used by millions, face a familiar challenge: how to deliver fast, high-quality customer support as demand for help continued to grow. It’s ticket-based system worked, but at scale, it created friction. Customer had to leave the product to get help, and support teams were overwhelmed with repetitive requests. The team was handling thousands of tickets each month, often spending close to 10 minutes on routine requests. A previous AI assistant had been introduced to help, but it struggled to resolve issues effectively, leaving most requests to escalate to support agents. After adopting Atlassian Customer Service Management (CSM) and embedding AI directly into the product experience, Loom transformed support from a reactive function into a proactive driver of customer engagement–resolving 80% of inquiries with AI and reducing chu...

Build AI-powered Forge apps with Atlassian-hosted LLMs

Teaching AI to speak our design language People are using AI to design and code every day, but AI tools are only as good as the context they receive. At Atlassian’s scale, information about our design language is spread across our systems: documentation sites, Confluence pages, Figma files, Looms, and hundreds of packages in code. Some sources are thorough, but others are missing key details, are out-of-date, heavy on images and visual information which can’t be read by code. Most are designed for people to view, not for machines to read effectively. When AI tools try to generate Atlassian UI from this fragmented landscape, the results are unpredictable and cost more than they should. Agents find outdated patterns, miss accessibility requirements, or invent components that don’t exist in our system. When we looked for solutions, we couldn’t see anything in the industry that had solved this at scale. So we set out to fix this by restructuring design system content into a coherent schema, providing the right level of context for AI tools to build Atlassian UI. We called this ‘structured content’. What structured content looks like in our design system Structured content, broadly, is content broken into consistent, machine-readable chunks instead of freeform prose. For example, an icon’s description appears in multiple places across the design system website, code, and Figma libraries. Consistent metadata is reused across different tools and locations, rather than being duplicated and eventually drifting out of sync. AI pushed us to take this approach further. Every component, token, and other element needs its details captured in a consistent, lightweight, and machine-readable format. We developed new content schemas for Atlassian Design System components, icons, tokens, lint rules, and foundational guidelines. The schemas provide a consistent format that covers usage, code examples, props, content standards, and accessibility requirements. Schemas live in TypeScript files alongside the code. From this sourc...

Build AI-powered Forge apps with Atlassian-hosted LLMs Summary The Forge LLMs API is now officially in Preview release and can be enabled on production environments. Developers can call Claude models directly in Forge, making it easy to create AI-powered app features without dealing with model integration or infrastructure. Forge LLMs run entirely in Atlassian’s secure environment, with no data egress, so apps that use it can qualify for the Runs on Atlassian badge . Keep reading to learn how you can go from zero to your first LLM call in just a few easy steps. LLMs have become a core tool in every app developer’s stack, powering features that feel almost magical. Users can query data with natural language, summarize long issue threads, and get smart, contextual suggestions, in an instant. Just a few years ago, these features would have been cumbersome or even impossible for developers to build. AI features clearly provide a ton of useful functionality for app users, but developers integrating LLMs have to deal with trust considerations and complexity. Where is data going and how is it moving between systems? Is my model infrastructure scalable and compliant? That’s why we’re excited to introduce the Forge LLMs API . The Forge LLMs API allows developers to call large language models hosted natively on Forge. Data stays on-platform, reducing risk and operational overhead. And because requests are routed only through Atlassian-managed infrastructure, apps that use Forge LLMs can still qualify for the Runs on Atlassian badge. “With the Forge LLMs API, we’ve been able to give our customers something they couldn’t get anywhere else: an AI that orchestrates their entire delivery lifecycle inside Jira, with no data leaving their Atlassian tenant. That data protection assurance has opened doors with enterprise and government customers that were previously closed to AI tooling entirely.” — Brett Taylor, CEO, BluBees Try it out It’s easy to get started . Because Forge handles model integration for you, you can skip the set-up and...

How We Cut up to 80% of Engineering “Chores” Using AI Agents in Jira

The future of product craft: Why AI-native PMs build better products, not just work faster

Advancing modern teamwork AI thinking and product news to unleash the potential of teams

How We Cut up to 80% of Engineering “Chores” Using AI Agents in Jira Our Jira engineering team was spending more time than we’d like focused on KTLO (keeping the lights on) tasks – the small, but important maintenance tasks nobody wants to spend time on. This includes work like cleaning up old feature flags, chasing flaky tests, fixing identified vulnerabilities, addressing accessibility issues, and chipping away at a long tail of bugs. As a team we wanted to shift our time towards enabling our engineering org to move faster with best-in-class tools, not just keep tech debt at bay. So we devised a way to use agents, Jira, and workflows to cut up to 80% time on key automated repetitive tasks. Jira is the heart of our strategy. Each work item is a record of the tasks we need to complete and acts as a prompt for agents. All the context an agent needs is shared using the work item, Atlassian’s Teamwork Graph , and the explicit instructions we include in our workflow automations. Our team has spent years fixing these exact categories of issues. That pattern recognition is what makes delegation to agents possible. We know what good cleanup looks like, so we can define clear parameters, build review checkpoints, and design a human-in-the-loop system that produces code meeting our standards. For our team, Jira isn’t just where work is tracked. It is where agents are given context, assigned work, and where our team controls what agentic work is actually merged into our codebase. Here are two examples of applying this framework to automating some of our engineering “chores”: How to fix flaky tests faster with AI agents in Jira Flaky tests are one of those maintenance problems that look small in isolation, but create real drag over time. They interrupt builds, reduce trust in CI, slow down delivery, and pull engineers away from product work. Our team previously spent two hours resolving a flaky test. We encountered roughly one flaky test per day, sometimes more. Each required an engineer to inspect the CI failure, reproduce the issue locally or...

From alert noise to action: How 24 Hour Fitness transformed IT operations with Jira Service Management and Rovo Ops How a modernized IT Ops team cut alert noise, slashed ITSM costs by 37%, and built a fully connected Ops platform that traces change and reclaims on-call sanity. The learnings in this blog post are based on the session, “From alert noise to action: How 24 Hour Fitness modernized IT Ops with Jira Service Management”, presented at Atlassian’s Team ’26 conference. You can check out this session and others on demand. Across hundreds of fitness clubs in the United States, the 24 Hour Fitness IT Ops team is responsible for keeping critical systems running for members, employees, and club operations. Their work goes beyond building applications; the team also owns the day-to-day reliability, incident response, and operational processes that keep the business moving. Before Jira Service Management , IT operations at 24 Hour Fitness were an uphill battle: No automated on-call system . They had a homebrewed, static on-call schedule with no overrides, nothing dynamic. A human had to read alert emails coming from monitoring systems and manually figure out who to wake up at 2 a.m. Constant context switching. Once an engineer got the call, they had to log in, create an incident ticket, flip over to monitoring and telemetry tools, then flip back to the ticket to take notes. Disconnected data. Change records and incident records lived in different systems for months, so teams couldn’t reliably connect an outage to the change that caused it, or see downstream impact across locations. No change to incident traceability. If a deployment caused an incident (or dozens of incidents across multiple clubs), there was no way to trace it back. People made changes under the table because the old system was so onerous to work with. Top 4 issues for IT Ops teams not on Jira Service Management Too many alerts — a flood of notifications, many with zero actionable value Disconnected Dev and Ops tools — teams working across separate systems, without shared context for changes and incidents, or a si...

The AI-native SDLC is paying off: 19% more PRs and 2–3 hours saved per developer per week Reimagining software development around an AI-native SDLC AI is now a core part of how software gets built. 93% of developers use AI tools and nearly 30% of code is AI-authored [ source ]. Code generation has been the first breakout use case for developers but it is not the end of the story. The next chapter is AI at every stage of the Software Development Lifecycle (SDLC): Plan, Orchestrate, Code, Review, and Operate. That requires reimagining software development around a new AI-native SDLC, and building new measures to capture the impact AI is having on it. In this analysis, we focus on the parts of that shift where we have the strongest data today: coding and review workflows in Rovo Dev, measured through PR throughput and developer time saved. The role of the developer has changed already Atlassian’s State of Developer Experience report shows how quickly the developer role is changing. In 2024, only 38% of developers reported saving any time at all with AI. In 2025, 99% of developers said they were saving meaningful time every week, and re-investing this time towards improving the broader system around code such as code quality, engineering culture and documentation. But as AI accelerates building in the code phase, bottlenecks to the left and right of code become more pronounced. Clear planning, strong code review, testing, documentation, and operations matter even more when teams are managing a growing volume of agent generated outputs. The productivity challenge now for developers is how well they can orchestrate the entire system of work around the SDLC. Next come agents at every stage of the SDLC What comes next is AI doing meaningful work at every stage of the SDLC, not just code generation. We believe agents will partner with humans at every stage: The AI-native SDLC Plan: Humans establish intent and requirements. Agents draft technical breakdowns, estimates, and work items. Ideas become structured, executable plans a human can review, iterate on, and ap...

The future of product craft: Why AI-native PMs build better products, not just work faster AI use is accelerating across the modern enterprise. Teams are moving faster. The barrier to building will continue to drop. But the cost of building the wrong thing is about to skyrocket, because teams can now ship more of it, faster. Atlassian’s State of Teams 2026 report found that 89% of executives say AI has increased the speed of work. But only 6% feel confident they can point to specific organisation-wide AI ROI. That gap is a sign that speed, on its own, doesn’t actually create better products. After watching hundreds of product managers across Atlassian navigate this shift over the past year, we think solving the speed‑without‑ROI problem is less about tools and more about three changes in how product teams work. The job hasn’t changed. How you do it has. 1. Product craft is still the differentiator The PMs who thrive won’t be the ones who use AI most. They’ll be the ones who use it with sharper judgment, who know what’s worth building and why. Atlassian’s AI Collaboration Index found that teams who treat AI as a shared partner, rather than a personal shortcut, see 2x the ROI on their AI efforts. The difference isn’t adoption. It’s judgment about where to apply AI and when to override it. AI changes how you work. Your judgment is what makes it count. 2. AI collapses the distance between idea and evidence Product managers have always sat between the customer and the solution. The problem was the distance: commission the research, wait for the readout, translate for the team, review the mocks, ship, and hope for the best. AI compresses that loop. PMs can now prototype ideas, query customer data, and test concepts directly, not to become designers or engineers, but to develop ‘product builder’ skills. That means flexing into areas that were previously out of reach. The closer you are to the work, the sharper the craft. So, discover faster, validate sooner, and communicate with a working prototype, not a document. 3. The PM’s job is to rewire how the team learn...

RFC-137: Forge Module for AI Skills RFCs are a way for Atlassian to share what we’re working on with our valued developer community. It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early. Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks! Project Summary We are introducing rovo:skill , a new Forge module type that lets developers define AI skills directly inside a Forge app. A skill is a named, reusable AI capability backed by a SKILL.md instruction file and optional Forge tools. In v1, those tools are implemented as Forge action modules from the same app. When an app with rovo:skill modules is installed, those skills are automatically registered with the Atlassian Skills Registry, making them discoverable by Rovo Chat and other Atlassian agents without any additional configuration. This RFC describes the developer experience, manifest design, packaging pipeline, skill lifecycle, end-user experience, and open questions we’re working through. We’re seeking feedback from Ecosystem partners before we finalise the implementation. Publish: 29 May 2026 Discuss: 12 June 2026 Resolve: 17 June 2026 Problem Forge developers can already expose callable capabilities to Rovo Studio agents through Forge action modules, and those actions can appear as ‘skills’ (soon, tools) in parts of the current UI. However, that model does not give developers a first-class way to package reusable skill instructions, examples, and supporting files that an agent can load at runtime. Today, ...

"Get users from group" no longer shows email addresses for "app" users (Atlassian Service Accounts) Previously, the Get users from group API (ex: YOURSITE.atlassian.net/rest/api/latest/group/member?groupId=YOURGROUPID ) would return an emailAddress for Atlassian’s new(ish) Service Accounts . Recently, this has changed. For an account with an email like: sa-something-123456@serviceaccount.atlassian.com , the emailAddress is simply missing from the response. I don’t recall if those accounts previously had the accountType of app but they do now. It seems like Atlassian is having difficulties figuring out how to treat Service Accounts vis-a-vis regular accounts. Since their introduction if you looked that same group in a site’s Groups UI, the SA would not be visible. The only way you can view and edit an SA’s Group memberships in the SA admin interface for each one. Which I suppose makes sense - SA’s are “global”, and groups are site-specific. (Although we are still a non-Vortex organization, not the centralized user management experience.) Still it’s frustrating that the automation I wrote to pull all members of a group, including email addresses, is now broken. 2 posts - 1 participant Read full topic

Is AI flattening your team’s creativity? Here’s how to tell.

Advancing modern teamwork AI thinking and product news to unleash the potential of teams

Atlassian Design System: Building the context engine for the AI era Design systems are no longer ‘just’ about consistent UI and component libraries. They’re strategic capabilities that harness design intent, drive coherence and accelerate a team’s ability to innovate. Here’s how the Atlassian Design System (ADS) is evolving to be a full stack context engine to meet the demands of an AI-native future. Maria Christley is the Head of Design for the Atlassian Design System, leading over 35 designers globally across Design Language, Accessibility, Systems Architecture, and AI. She is a 2025 Women Leading Tech finalist and has spoken at Figma Config and UX Australia. Rachel Radford is a Design Manager on the Atlassian Design System team, where she leads designers working on the systems, components, and practices that power Atlassian’s products at scale. She is a founding leader of Friends of Figma Wellington, New Zealand. Design Systems with Figma – Sydney The value of a design system has never been higher Whether it’s 2016 or 2026, certain truths about working in design persist. Seeking buy-in is hard. Brand coherence is always at risk. Knowing which design decisions have been made, and how to apply them correctly remains elusive at scale. These aren’t new problems. But the expectations around them are accelerating. Competitive landscapes are shifting faster, and customers notice the gap between products that feel considered and those that feel assembled. Design systems have a leading role to play in how companies close that gap, and we believe the value of the design system has never been higher. Today, design systems play a leading role in: Front-end infra Components are deeply connected to the codebase and engineering practices. They are part of the performance and reliability story, not just the visual layer. This layer is now more agentic than ever in how it show up to designers and developers via the tools they use, ultimately making it easier and faster to produce high quality artefacts. Fluid collaboration, not linear handoffs. T...

How AI is Changing Developer Workflows: Lessons From Engineers I sat down with engineers who use AI coding agents for the vast majority of their implementation work. Stack Overflow’s 2025 Developer Survey found 84% of developers using AI agents for software development are using them for actual implementation work, so I wanted to understand what that looks like up close. What I heard reshaped how I think about where developer tools need to go next. This piece covers what those engineers actually spend their time on, where trust in AI breaks down, and what that means for the tools built to support them. What is AI-native developer work? AI-native developer work means writing code is no longer the primary bottleneck. Engineers use AI agents to handle the bulk of implementation. They write the prompts, review the output, and spend the rest of their day on everything the agent can’t do alone: gathering context, planning work, and making judgment calls. The most rigorous study to date, a randomized controlled trial from METR , surfaced just how much the work around the code shapes whether AI tools actually help. What is changing in AI-native developers’ workflows? Most of the day goes to context, not code When I asked engineers what takes up most of their day, almost none of them pointed to writing code. They pointed to everything that happens before an AI agent can be useful: gathering context. The pattern came up in every interview. Download a PDF from the wiki. Paste it into a chat. Open the repo, copy the file path. Find the right person, message them, wait for a reply. Re-read the architecture doc someone wrote eight months ago. Stitch together enough context for the agent to do something useful. Then prompt it. Then review. I have to manually go through and find all the relevant docs. It’s scattered across our wiki, Google Docs, Slack threads, email. Very time consuming.” In 2026, code generation is fast. Context assembly is slow. That gap is where most of the friction in AI-native development lives. Atlassian’s State of Devel...

How to shift your mindset from “AI as a tool” to “AI as a partner”

Advancing modern teamwork AI thinking and product news to unleash the potential of teams

Trouble accessing service-desk-ops api Hi, I am using my service account token (it has proper accesses granted) to do stuff with Jira, but also check teams on call schedules etc. It works properly for Jira api, where I am using this base url: “ https://api.atlassian.com/ex/jira/{cloud_id} ” But when I am trying to check stuff from service-desk-ops, API I am getting 401 unauthorized. The documentation ask for customerID, but I am not sure what that is, and why is that different that cloudID? developer.atlassian.com About.css-1afrefi{display:inline-block;-webkit-flex-shrink:0;-ms-flex-negativ...... This is the reference for the Jira Service Management operations REST API. The REST API is for developers who want to integrate Jira Service Management operations with other applications or administrators that want to automate their workflows and... I am getting: RuntimeError: Failed to list Jira Ops teams: 401 Client Error: Unauthorized for url: ``https://api.atlassian.com/ex/jira/{cloud_id_masked}/jsm/ops/api/v1/teams/{team_id_masked}/roles How do I get the customerID? What is that, or is it just old documentation, and no one noticed it? Is the URL I am using okay? The authentication I am using (bearer token in header) should be working fine, since it works for Jira stuff. 1 post - 1 participant Read full topic

Routing on full page module not working anymore Since today the routing in the confluence:full-page module is broken. It suddenly gets the whole route instead of the route from the defined routePrefix. When i try to route within the app i get this warning and a 404 not found page. This is on a development environment but production apps also have stopped working. 2 posts - 2 participants Read full topic

From cost center to growth engine: 5 lessons from Leadership Circle’s AI-first support transformation How a global leadership development company implemented human-AI collaboration to serve 3 million customers across 21 languages, and turned support into a revenue driver. The learnings in this blog post are based on a discussion from Atlassian’s Team ’26 conference. You can check other sessions like this on demand. Leadership Circle is a global leadership development company whose mission is to evolve the conscious practice of leadership through data-driven 360-degree assessments, coaching, and consulting. With 3 million customers and partners across 21 languages, and a network of over 12,000 certified practitioners worldwide, they needed customer support that could match the scale and quality of their work. In looking to modernize their support practice, they turned to the Customer Service Management app, Atlassian’s AI-first, purpose-built offering for external customer support. Before CSM, our help content was buried on our website, our cases lived in NetSuite, and nothing was connected. Now, with Atlassian CSM, we have one unified experience — self-service, AI, knowledge base, and ticketing — all in one place , making it easier for our team to quickly find information and trust that it’s current and approved, across 21 languages.” –Miranda Dunn, Director of Global Transformation and Change, Leadership Circle After implementing Atlassian’s Customer Service Management (CSM) app, Leadership Circle achieved a 71% AI resolution rate, a 65% reduction in manually handled tickets, and a support function that now actively drives revenue while delivering the best possible customer experience. Here’s what we learned as we worked with Leadership Circle as an early adopter of the Customer Service Management app: 1. Measure resolution, not containment The customer service industry has a metrics problem. As AI tools proliferate, many organizations have become laser-focused on AI containment rates , which is the percentage of interactions handled without a human. AI containment...

Customfield typewith searchtype matching issueHistory() We have implemented custom field type with integer property that works with following JQL "My Custom related issue.id" in issueHistory() Anyway, it would be nice to provide autocompletition for such “issue” generating JQL functions. I suppose that new searchType “issue” similar to “user” would be helpful. 1 post - 1 participant Read full topic

Rovo - Edit option for custom rovo agent showing blank screen Hi Buddies, Not sure if you all are facing the blank screen issue when trying to edit your custom agent that you created using Rovo. We are facing this issue for last 2 days, whenever me or other TMs are trying to edit the agent, studio open with blank screen and no further progress…wating and keep on wating. Attaching the screenshot with you all. Please let me know if there is issue at from Atlassian side or its something that we need to check our site configuration etc. Thanks, Ranvijay Singh 1 post - 1 participant Read full topic

Query around External Backend access Hi, I’ve few queries around external backend URL access setup in Forge app manifest file. Below is my current implementation and my query Intention: Jira User / Admin fills up a form where they enter their ACCELQ(External System) credentials to establish connection between Jira and ACCELQ to allow REST API calls to hit ACCELQ server. Now we have two kinds of ACCELQ servers - On Cloud whose URL is *.accelq.io and On Premise URL where client have full control over domain name (*) So the question is will Forge allow setting up star as the value under external → fetch → backend. If not, then what are other options? ``` permissions: scopes: - read:jira-work - write:jira-work - read:jira-user - manage:jira-configuration - storage:app external: fetch: backend: - '\*.accelq.io' - '\*.ngrok-free.app' ``` 3 posts - 2 participants Read full topic

Bitbucket Connect to Forge migration tooling We have added some documentation around Bitbucket Connect to Forge migration tooling available today, including: How to make Forge app distribution link available to workspace admin How to use Addon client key API to perform data migration/app cleanup after Forge app install How to list your Forge app on marketplace and retain your Connect app’s metadata/reviews How to block installation of your Connect app when you are ready Please see Connect to Forge migration tooling for details. If you have not done so already, reminder to please provide your feedback on any friction points around the migration process at the form mentioned in the previous post here . Thanks Wendy 1 post - 1 participant Read full topic

From Ambiguous Questions to Action: Research Mode in Rovo Dev CLI

"forge build" command starting to fail with "invalid json response..." error This morning, when trying to execute: “forge build” I get errors like below. Any idea what is going on? Yesterday all was ok. If I try to open the URL mentioned in the error I get a 404 error. Thanks. root@LP-AST03526:/opt/RD/JiraCustomFieldPlugin/forge# forge build --verbose Building and uploading your app. Press Ctrl+C to cancel. Running forge lint... Error: invalid json response body at https://developer.atlassian.com/cloud/jira/service-desk/swagger.v3.json reason: Unexpected end of JSON input Error: invalid json response body at https://developer.atlassian.com/cloud/jira/service-desk/swagger.v3.json reason: Unexpected end of JSON input at lint (/root/.nvm/versions/node/v24.15.0/lib/node_modules/@forge/cli/node_modules/@forge/lint/out/lint/lint.js:131:15) at process.processTicksAndRejections (node:internal/process/task_queues:104:5) at async LintService.run (/root/.nvm/versions/node/v24.15.0/lib/node_modules/@forge/cli/out/service/lint-service.js:30:29) at async BuildController.verifyPreBuild (/root/.nvm/versions/node/v24.15.0/lib/node_modules/@forge/cli/out/command-line/controller/build-controller.js:71:33) at async BuildController.run (/root/.nvm/versions/node/v24.15.0/lib/node_modules/@forge/cli/out/command-line/controller/build-controller.js:49:13) at async /root/.nvm/versions/node/v24.15.0/lib/node_modules/@forge/cli/out/command-line/register-build-commands.js:48:16 at async Command.actionProcessor (/root/.nvm/versions/node/v24.15.0/lib/node_modules/@forge/cli/out/command-line/command.js:283:28) at async Command.parseAsync (/root/.nvm/versions/node/v24.15.0/lib/node_modules/@forge/cli/node_modules/commander/lib/command.js:1104:5) at async Command.parse (/root/.nvm/versions/node/v24.15.0/lib/node_modules/@forge/cli/out/command-line/command.js:165:13) at async main (/root/.nvm/versions/node/v24.15.0/lib/node_modules/@forge/cli/out/command-line/index.js:94:5) root@LP-AST03526:/opt/RD/JiraCustomFieldPlugin/forge# 4 posts - 3 participants Read full topic

Market place app version is not updating Hey everyone I built a Forge app, listed it on the Marketplace, and when I deploy from local to production the version doesn’t update in the listing at all. I’m deploying via CLI. The app ID matches, everything looks fine, but the Marketplace still shows the old version. Has anyone run into this? Is there something I’m missing in the deploy flow or the Partner Portal? Any help appreciated 1 post - 1 participant Read full topic

From Ambiguous Questions to Action: Research Mode in Rovo Dev CLI Not every developer question starts as a coding task. Sometimes the hard part is figuring out where to look: Jira for work history, code for implementation truth, Confluence for product context, or pull requests for how decisions landed. Research Mode in Rovo Dev CLI came from that experience. What shipped We shipped Research Mode as a structured workflow for investigation before action: it breaks an ambiguous question into research domains, chooses top-down or bottom-up direction per domain, sends subagents to investigate, runs another round when dependencies exist, and returns a final report with references and next-step options. See how research mode works: The pain points Users were asking questions that were bigger than “edit this file”: Which work items are ready for automation? Why does this problem happen, and what mitigations exist? Which bugs or security issues keep resurfacing across work items? What decision led to this architecture? What evidence do we have for a launch or roadmap decision? Prompt tuning helped the agent ask better questions, search more sources, and write cleaner summaries. But the core problem was not just prompt quality. It was research strategy. From better prompts to a research workflow We borrowed from how research is normally done: define the question, split it into subquestions, gather evidence, compare findings, and write a synthesis. In Research Mode, those subquestions become research domains . Each domain starts with a search direction. That direction gives the agent a path through the available evidence. For some domains, the right path is top-down: Built on the permissions you already have, Research Mode only reads from the sources a developer already has access to. It runs on demand when a developer invokes it for a specific question, not in the background, and not across teammates’ private work. The agent’s scope is bounded by the same access controls that govern Jira, Confluence, and Bitbucket today. For other domains, ...

Advancing modern teamwork AI thinking and product news to unleash the potential of teams

Migrating a Connect + Spring Boot app to Forge Remote (and Containers) without rewriting your service layer Hi everyone, If you still run a Connect add-on on Spring Boot and need to move to Forge Remote , the usual fear is a full rewrite: new auth model, new Jira clients, new tenant keys, new UI, new manifest — all at once. To avoid a massive rewrite, I built and open-sourced atlassian-runtime-bridge . It handles the infrastructure differences for you, so you can run the exact same Spring Boot backend across Connect , Forge Remote , and Forge Containers without changing your business logic. Migration phases: What changes vs. what stays Phase What you change What you keep Hybrid Add Forge Custom UI + remotes; keep Connect iframe for a while Same Spring app, same controllers Forge Remote Remove connectModules from manifest; UI is Forge-only Same Spring app, same business code Forge Containers (optional, harder) Run Spring in a container; storage → Forge SQL / KVS Same service abstractions, different bridge module + data layer The library only standardizes the boring part: who is the tenant and how do we call Jira on each runtime. Step 1 — Fix tenancy before you “go Forge” This was the biggest data-model mistake to avoid: Your tables should not hang off AtlassianHost.clientKey or FK into Connect’s host table. Use cloudId (or installationId where needed) as your tenant key. Know the difference: cloudId is permanent for the tenant. installationId changes completely every time a customer uninstalls and reinstalls your app. If you tie your domain data to installationId , that data becomes orphaned on reinstall. During transition, a small mapping table (cloud_id, client_key) is enough: resolve cloudId first , fall back to clientKey only for stragglers on native Connect (if any remain). Migration is about restructuring your database to use cloudId , not dragging legacy Connect tables into your new architecture. Step 2 — One backend, two transports (hybrid → Forge Remote) While hybrid: Connect iframe still hits your app with Connect JWT. Forge Custom UI hits the same baseUrl via re...

OAuth 3LO "failed to retrieve client" for non-contributors despite Sharing mode enabled I have a private OAuth 2.0 (3LO) app registered in developer.atlassian.com . It’s a Flask web app that authenticates users against a Jira Cloud instance using the standard authorization code flow. The problem: Users who are not the app creator get a “failed to retrieve client” error on Atlassian’s authorization page. The app creator can authorize fine. What I’ve done: Enabled Sharing under Distribution (toggled on, hours ago) Added a Privacy Policy URL Verified the callback URL in Authorization → Configure is correct Confirmed the client_id in the app matches what’s in the authorization URL My authorization URL structure: https://auth.atlassian.com/authorize?audience=api.atlassian.com&client_id= &scope=read:jira-work+write:jira-work+offline_access&redirect_uri= &state= &response_type=code&prompt=consent Questions: Does enabling the Sharing toggle require any additional step to take effect, or is it immediate? Is there a known propagation delay after switching from Development to Sharing? Is there any reason “failed to retrieve client” would persist after Sharing is enabled? 1 post - 1 participant Read full topic

Introducing Cursor in Jira

Is AI flattening your team’s creativity? Here’s how to tell. Think about your to-do list for a given work week. From responding to a colleague’s quick message to building a team strategy, how do you prioritize how much time and energy to allocate to each task? Behavioral science tells us most of us don’t optimize; we satisfice — we find the first “good enough” option, and we move on. The term, a mash‑up of “satisfy” and “suffice,” was coined by Herbert A. Simon, a mid‑century Nobel Prize–winning economist and sociologist who studied workplace decision making. Satisficing, Simon argued, is a pragmatic way to work, especially for quick-turn, low-stakes tasks or for complex decisions where the complete picture is ambiguous or unknowable. But while satisficing may have made sense for generations of workers, AI has rewritten the rules. Now, “good enough” appears instantly, often before anyone thinks deeply about the question or challenge at hand. That speed might be great for the small stuff, but when it becomes the norm for everything, teams risk sliding into sameness, shallow reasoning, and — at worst — making the humans in the equation entirely irrelevant. Atlassian’s view is simple: AI should amplify human judgment, not replace it. But given our natural inclination to satisfice, that won’t happen by default. Teams need to intentionally decide how and when to invite AI into the room, choosing the mode of collaboration that best fits the project at hand. This post introduces the AI Collaboration Framework : a tool designed by Atlassian’s Teamwork Lab that teams can use to turn the dial from AI‑first to human‑first thinking, depending on the needs of the project. Use it to safeguard the capabilities that make your people valuable: human judgment, taste, and the ability to think deeply and originally. Why over‑reliance on AI is risky: three evidence‑backed pitfalls Pitfall 1: AI‑induced groupthink Good leaders don’t let the loudest voice go first. They use techniques like brainwriting to surface diverse ideas before discussion. Bu...

Introducing Cursor in Jira Starting today, Jira teams can assign work directly to Cursor, where a cloud agent will pick it up and begin working. You can steer agents directly from Jira, your IDE, or Cursor on the web. When Cursor needs input or is ready for review, it will notify you in Jira. When it opens a pull request, it will be automatically linked back to Jira. Based on a multi-year DX study of AI usage and engineering throughput, we’ve seen developer velocity failing to keep pace with model capability because agents lack context. The respondents cite things like context switching, planning, alignment, bug triage, and review as primary friction points outside of their IDE. Now, Atlassian is enabling AI-native workflows right from Jira for any engineering team using Cursor. “The question we’re asking isn’t how do we get engineers to use more AI. It’s how do we build a system where humans and agents are working from the same context, toward the same goals. Assigning work directly to Cursor from Jira, with all that rich context, is a meaningful step towards being able to orchestrate agents effectively at scale.” Jason Andrews Vice President – Engineering Operations , Cisco Intent to action with Cursor in Jira: Trigger agents directly from Jira : Assign a work item to @Cursor or mention @Cursor in a comment to start a new agent session for the task at hand. Automate workflows : Create rules that automatically assign certain tasks to Cursor, helping you tackle repetitive work and improve code quality. Enable the whole team to make changes : Any team member can use Cursor to start tasks and open a pull request, without needing to set up a local dev environment. Work with rich context : Use Rovo to enrich your task with context from across Atlassian’s Teamwork Graph, then assign to Cursor so it has more context with less manual effort. Enable spec-driven development flows: Automatically sync agent-readable specs with collaboration documents in Confluence, and work items, plans, and goals “We’r...

Customer-managed egress: Feedback on Dialog Here is my first feedback for the Dialog for the Customer-managed egress. Wild-card doesn’t include main domain. For example I want to use .github.com. (for like api.github.com , git.gisthub.com ). The ‘’ doesn’t include the main domain, from my initial testing. This then adds the extra listing / duplication on the approval dialog. → I would love to have a way to allow the main domain including sub-domain. Or have the wild-card allow the main domain as well. What is the difference between ‘Image’ and ‘Media’. Why this difference? This looks to me like ‘implementation’ details leaking into the UI. As a end user a ‘image’ and a ‘media’ is very, very similar. Both can show stuff. The main difference is (I assume), that media can include audio. And makes video more efficient. → Generally, as a admin I don’t care about this difference. The other categories make sense. Links require the Fetch client side permission? I’m not 100% sure yet. But if that is true, it feels a bit odd / clunky. Having ‘working’ links without any pop-up is something everyone is used to. Having that requiring ‘Fetch client side’ permission is very odd. The listing gets quickly very, very long, because each allowed type needs a row (see screenshot) The performance of the Dialog is awful. (At least for EU, but it seems more than just a rountrip issue). Its about 2 seconds! The network round-trip is way lower. It just feels broken / the app is hanging if you call it. 1 post - 1 participant Read full topic

Unable to get the download link to download the id-mapping We are in the process of migrating to a Jira cloud site from a Jira Datacenter server, but we have internal systems that have been relying on the id’s in REST JSON, we therefore need to update these references when we migrate, and according to the documentation the https://api.atlassian.com/migrations/reports/v1/id-mappings endpoint should be able to provide the mapping, but unfortunately it doesn’t work. We can trigger the report creation and get a response like this: {“jobId”:“76fd9337-1eba-46e7-808c-4409941c2602_5056b3ad-fca3-4409-9ab5-a4bc41744d35”,“status”:“SUCCESS”} But when we go to the /download endpoint to get the download url, we just get: {“timestamp”:“2026-05-20T13:02:52.965+00:00”,“path”:“/migrations/reports/v1/id-mappings/76fd9337-1eba-46e7-808c-4409941c2602_5056b3ad-fca3-4409-9ab5-a4bc41744d35/download”,“status”:504,“error”:“Gateway Timeout”,“requestId”:“a49e4425-268 0637”,“message”:“Response took longer than timeout: PT14S”} Regardless of the number of retries we get the same response. I have also tried triggering a new report generation, but the result is the same, it succeeds and then just timeouts when attempting to get the download link. 1 post - 1 participant Read full topic

Agentic Pipelines now supports Claude Code

Agentic Pipelines now supports Claude Code Last month, we introduced Agentic Pipelines , a new way to orchestrate AI agents to automatically, and routinely, handle the repetitive engineering chores so you can get back to solving the fun, cool problems. When we launched, Agentic Pipelines supported Atlassian’s developer AI agent, Rovo Dev. Today, we’re opening up Agentic Pipelines to even more teams: You can now run agentic steps in your pipeline with Claude as the provider. We still support Rovo Dev as the default provider, but if your team is already using Claude Code, you can plug it directly into your Bitbucket Pipelines without any extra infrastructure or integration glue. Agentic Automation with Claude Agentic Pipelines evolves Bitbucket Pipelines from automating CI/CD tasks, to automating all kinds of automate all kinds of workflows using AI agents, with Bitbucket acting as the central orchestration platform. This is perfect for all the tasks before and after code creation that are low-value, high-effort, and highly repetitive. Think tasks like updating READMEs, triaging security reports, cleaning up feature flags, generating PR descriptions; before Agentic Pipelines, most of these tasks were manual, tedious, and difficult to automate, but with Agentic Pipelines, dev teams can automate these types of tasks with AI agents just by embedding them into their pipelines as a step in a repository’s pipeline configuration. And now, for your teams using Claude, they can do the same just by including the provider keyword in your bitbucket-pipelines.yml, like this: definitions: agents: my-agent: prompt: "Explain this repository" provider: claude pipelines: default: - step: script: - agent: my-agent If you don’t include provider: claude, Bitbucket will automatically default to using rovodev. Using Claude Code with Agentic Pipelines falls under our Third-Party Product agreement. Your source code, prompts and logs will be sent to Claude Code and Atlassian is not responsible for the privacy, security or costs involve...

How your approach to AI impacts teamwork

Advancing modern teamwork AI thinking and product news to unleash the potential of teams

The AI efficiency paradox: What to do when AI boosts productivity but not results 5-second summary: Most teams are using AI more, but leaders are struggling to understand and measure ROI. When AI speeds up individuals but not teams, companies pay the cost. Atlassian estimates this “fragmentation tax” costs the Fortune 500 $161B a year. The fix: treat AI as a team player, not a personal productivity hack, and bake it into everyday workflows so teams ship for quality, not just quantity. There’s a paradox happening with AI: Usage and productivity are up, but bottom-line results aren’t always as obvious. It’s a familiar pattern you might be seeing in your organization: Leadership invests in AI, and employees say they’re getting more done: more code, more campaigns, more analysis. Yet team and business outcomes tell a different story. When leaders look at outcomes — customer impact, work quality, and cross‑team alignment — it’s hard to point to clear, company‑wide gains. In Atlassian’s State of Teams 2026 report , which surveyed 12,000+ knowledge workers and 170+ Fortune 1000 executives around the world, 89% of executives say AI has increased the speed of work, but only 6% feel confident they can point to specific organization-wide AI ROI. This is the AI efficiency paradox: as AI helps individuals work faster, the surge of output backs up at reviews, approvals, and other human‑judgment gates, slowing down the flow and wiping out the speed gains. As one Vice President of Talent and Business Strategy at a Fortune 500 retail company told our researchers, “You think you’re moving faster, but you discover a quality gap and what we thought might be 20% faster gets pulled back.” To get more return on AI investments, leaders have to understand why this is happening and how to fix it. Faster output is creating bigger bottlenecks To understand the paradox, it helps to look at where time really goes in modern knowledge work. In most teams, only about 20% of the work involves individual production: writing code, drafting documents, creating designs, running analy...

Action Required: Atlaskit dropping support for Typescript 4 Hi Atlassian Developer Community, We’re writing to let you know that Atlaskit will remove typescript@4.x support and ship exclusively for typescript@5.x (Atlaskit uses v5.9) or newer after June 15th 2026 (approximately 1 month from this notice). Atlassian products utilise Typescript 5.x (as of 3 years ago), and none of them rely on the legacy types anymore. Atlaskit aims to swap back to a single version of types with a minimum supported range of 5.0. Who is affected? Customers and partners building custom UI, or using the Connect framework, that utilise our Atlaskit components, and who build with Typescript 4 could be affected. Note that the breaking type changes may not affect all packages. If you’re currently consuming @atlaskit packages in projects that compile with Typescript versions between 4.5 and 4.8 , you could be negatively affected when you update to the next major version of these packages released after Jun 15, 2026: { "name": "@atlaskit/foo", "version": "x.y.z", "types": "dist/types/index.d.ts", - "typesVersions": { - ">=4.5 - "*": [ - "dist/types-ts4.5/*", - "dist/types-ts4.5/index.d.ts" - ] - } - } } How to check if you’re affected? Check whether you’re directly depending on and building with typescript@4.x in your project(s). Next steps You won’t be immediately impacted . This change will only occur when you attempt to upgrade your Atlaskit dependencies to future major versions which have dropped support for TS4. You can continue using your existing package versions without concern. Once legacy types are removed, know that you may not be able to upgrade to the newest releases without first upgrading Typescript. Please consider upgrading to Typescript 5 as soon as possible . This upgrade is expected to be minimal effort in most scenarios. Typescript upgrade guidance When upgrading to TypeScript v5+, any new errors that surface don’t indicate a regression as those issues always existed, but the previous compiler version wasn’t strict enough to detect ...

Just shipped my first Forge app — 10 lessons after 11 days on the Marketplace Hey everyone, I shipped GanttBoard for Jira on April 23 — a free Gantt chart Forge app for Jira Cloud. 11 days in, 4 installs, 0 reviews. Below are the lessons I think are worth sharing for anyone considering a Forge launch. What worked Forge KVS for app-specific state worked exactly as documented. Zero infra setup. api.asUser() everywhere kept the security review trivial. Marketplace approval in 2 days. Cloud-only, no DC kept scope sane for a solo dev. Recommend. Landing site on GitHub Pages — mwefky.github.io/ganttboard-for-jira — free and fine. No domain needed for v1. What didn’t Hand-built deep-link URLs in router.open(url) broke on team-managed Kanban projects. The structured router.open({ target: 'module', moduleKey, projectKey }) form is more robust. I shipped the regression in 3.15.0 and removed the feature in 3.15.1. Marketing posts to my LinkedIn network got 13 followers but ~0 install attribution. My network isn’t Jira admins. Lesson: paid distribution matters more than I thought. Atlassian Community launch post got my main community account banned for review-solicitation phrasing. Avoid “a review helps a new app” — auto-mods flag it. Open questions for the room For other solo Forge devs: what’s actually worked for your first 100 installs? Anyone gone through Apptoberfest? Does the demo competition meaningfully move installs? Atlassian Developer Community vs the regular Community — am I right that this forum has different rules / culture for Marketplace publishers? App in the Marketplace if anyone wants to look: Atlassian Marketplace GanttBoard for Jira | Atlassian Marketplace Free Gantt chart for Jira. Critical path, baselines, dependencies Genuinely interested in your stories more than my own. Happy to answer technical questions. -– Mina 3 posts - 2 participants Read full topic

The bottleneck keeps shifting: What AI is changing about how we build

Advancing modern teamwork AI thinking and product news to unleash the potential of teams

AI editing on my video How can I make edits with AI on my video? 1 post - 1 participant Read full topic

Inside Reddit’s IT playbook: Building for scale and AI-readiness The learnings are based on our recent webinar, “Inside Reddit’s IT playbook for AI and scale”. Check out this session and other conversations with customers on-demand. When Reddit grew from fewer than 400 people before 2020 to roughly 4,000 globally distributed employees today, it wasn’t just their headcount that changed. The mandate for IT changed with it. IT used to be a function that could “run the technology show in a dark server closet,” as Reddit Deputy CISO and Head of Corporate Engineering Sean Joerg put it. But IT has now become the glue that holds business processes, communication, and data together. In the AI era, that glue is under more stress than ever. In a recent session, Joerg walked through how Reddit’s IT and security teams became AI-ready by modernizing their system of work. Their journey offers a practical playbook for IT leaders looking to scale, reduce tool sprawl, and unlock AI without losing control. These three objectives are at the core of Reddit’s IT and security teams: Modernize at scale with a standardized system of work Build governance and guardrails that enable safe experimentation Get AI-ready by centralizing knowledge and driving cross‑functional buy‑in Along the way, Reddit expanded its use of the Atlassian Teamwork Collection , powered by Rovo for support, and also leaned into Loom for more effective communication through video. Modernization at scale By the time Reddit reached 1,000 employees, the old ways of working had hit a wall. Teams were scattered across tools, time zones, and inconsistent processes. “The ways that Reddit used to work five, six years ago truly don’t scale to 4,000 globally distributed employees… You’re suddenly interacting with a team that sits four or five time zones away. How do you effectively manage work between those disparate time zones?” –Sean Joerg, Deputy CISO and Head of Corporate Engineering, Reddit Early on, engineering had largely standardized on Jira. Business teams, however, were using a patc...

How to delete a developer space? How can I delete a developer space? I cannot find any way to do so from the menu. 4 posts - 2 participants Read full topic

Rovo Dev in Jira as my Spec Driven executor

Accelerated frontend development with RovoDev in a practical example

Structured Queries: Enhancing Search with Natural Language and Filters

Accelerated frontend development with RovoDev in a practical example How it started What happens when a project estimated at two to three quarters gets built in 14 working days? In 2022, the team built App Updates, a feature that gives organization admins access to release notes about Atlassian changes and controls over how they’re delivered ( Keep up with changes | Atlassian Support ). It was a great experience for admins, but every other user was stuck with basic in-product change notifications. By 2024, we started asking – why not give everyone access to App Updates? Seeing what’s new and what’s coming is valuable for every type of user, not just admins. But the project to build a public version was estimated at two to three quarters, and with competing priorities, it never got funded. Then we got Rovo Dev . The question became: how fast can we build a public version with AI-assisted coding, using just 2 part-time frontend engineers (each at ~30% availability) and 2 part-time backend engineers? The answer was 14 working days for a fully functional frontend, covered by unit tests. First pull request landed on Feb 19, 2026 where core frontend functionality was complete by Mar 6th. From there, the team spent another 5 weeks on analytics, integration tests, design alignment, and production hardening, making it 7 weeks total from first commit to production. For context, the manual estimate was 6 months. That’s over 3.5× faster. Knowledge graph Rovo Dev , similar to other AI, operates with patterns, a so-called “knowledge graph”. At a high level, AI functions as an advanced autocomplete system – it automatically completes content, even entire files, by selecting the most contextually appropriate options based on its training data, prompt, and current context. To get the best results, instruct the AI agent to “copy” or “create something similar” by providing specific examples that enhance its knowledge graph and ensure that autocomplete has relevant references to consult. Project knowledge wiki Every time you ask a question about your re...

Structured Queries: Enhancing Search with Natural Language and Filters If you’re like most people, you don’t remember the exact name of the page you edited three weeks ago—or the precise title of the document someone shared in a chat thread. What you do remember is usually higher level: who you collaborated with what it was about roughly when it happened what kind of thing it was (a page, a PDF, a pull request, a message) That’s the gap structured queries are designed to close. Structured queries let you search in natural language , while the system reliably extracts filters —like app/source , content type , time range , and people involved —and uses them to retrieve and rank results more accurately. What are structured queries? Structured queries = confidently-derived filters + residual query In other words, you type a normal sentence, the system identifies the parts that can be deterministically converted into filters, and treats whatever remains as a regular text query. There should not be any ambiguity in the query about whether some terms are filters or not. Example: Query: “gdrive docs about rovo from Mike” The system can infer filters like: App = GDrive Type = document User = Mike And it keeps the residual text query: Residual = “rovo” Definition: Structured queries are natural-language queries where we can deterministically infer filters (app/product, type/sub-type, time, user/activities, and—where supported—product-specific attributes). Why this matters When search can reliably understand “who / what / when / where” from the way people naturally ask, it unlocks high-value “hero” workflows—searches that save meaningful time and help teams move faster. Structured queries are especially useful when: the organization spans multiple tools (docs, chat, issue trackers, file storage, etc.) queries are ambiguous unless you apply filters users often start from partial memory (“I know it exists, but I can’t recall the details”) Three everyday examples (all in natural language) 1) “I worked on a Confluence page with Bhakti… it was about S...

3 ways AI alert grouping is transforming on-call engineering at Atlassian

3 ways AI alert grouping is transforming on-call engineering at Atlassian At Atlassian, on-call engineers live at the intersection of urgency and uncertainty. Floods of noisy alerts sap focus, energy, and productivity — especially when responders must decide what matters, what can wait, and what’s just noise. A single underlying issue can trigger dozens of near‑identical alerts in hours. In most queues, each one appears as its own row, even when they point to the same service or dependency — forcing engineers to open alerts one by one, repeat the same checks, and constantly switch context. When alert queues spike, even experienced responders can lose time to noisy, repetitive signals. That’s where AI‑alert grouping comes in. What is AI Alert Grouping? AI alert grouping is an AI capability in Jira Service Management – powered by Rovo – that automatically clusters similar alerts that occur within a rolling 24‑hour window into a single, durable alert group. By comparing alert titles, descriptions, and tags, it infers a shared root cause and clusters related alerts into one group. From that group, responders triage faster in a single, consolidated view, apply bulk actions, and still drill into any individual alert when needed. Mobile and Slack integrations will surface grouped alerts and actions where engineers work, further reducing context switching. AI-powered alert grouping in Jira Service Management is reshaping incident response for on-call teams at Atlassian in three key ways: Cutting through alert overload so engineers can triage faster Before grouping, on-call engineers faced long, cluttered queues where critical incidents mixed with repetitive noise. Every alert demanded at least a quick look, often a full open, just to confirm it was not unique. This raised cognitive load as engineers repeatedly scanned titles and payloads to check whether the system was saying anything new, while the volume of similar alerts made it harder to spot patterns or early signs of a larger incident. AI alert grouping collapses similar alerts into a singl...

The State of Nonprofit Teams 2026 How your approach to AI impacts teamwork Our latest data reveals that how teams implement AI, not just whether they do, determines the value it brings to effective teamwork. Learn about the benefits that 1/3 of nonprofits are realizing by balancing human and technology considerations in their AI rollouts. Read the report Key findings on the state of nonprofit teamwork in 2026 Our research into the effectiveness of nonprofit teamwork and AI implementation strategies revealed: Teamwork is evolving: 59% of nonprofit organizations are changing how they work, with 53% of nonprofit knowledge workers using AI at least once a week. Approaches to AI implementation differ: Half of nonprofit teams are taking a human-focused approach to their AI implementation. Teams see greater AI ROI when focusing on both humans and technology: Teams that take a balanced AI approach are 40% more likely to have clear goals and priorities, 40% more likely to have time and capacity to coordinate, and 50% more likely to avoid teams working on duplicative work. What is a human-focused vs. tech-focused AI approach? Human‑focused AI approach: AI strategy primarily designed around people – starting from their roles, skills, values, and workflows, then introducing AI in ways that support their judgment, relationships, and mission, even if that slows down adoption. Tech‑focused AI approach: AI strategy primarily designed around the capabilities of the technology – choosing tools, building integrations, and automating workflows to drive speed and efficiency, then asking people to adapt. Read the report for more data and a conversation guide to support teams in balancing human and technology considerations in their AI strategies. Read the report “ At the Atlassian Foundation, we believe the instinct to put people first is one of the nonprofit sector’s greatest strengths — and it shouldn’t be left behind in the pressure to adopt AI. Our research is clear: teams that pair their human-centered values with a...

How can i get a user reference attribute to synchronize from an incoming mapping via email address The schema-and-mapping does not include the schema entries for reference types (ie: User ). The process i followed was: Create the Schema named Users in the Assets web UI Assets → Schemas → Create schema Only the left nav: Create a blank schema Fill out the form: Schema name: Users Click Create schema On the schema page, Click Add object type Fill out the form: Name: User Icon: User Click Create Click the Attributes button to switch to Attributes view Fill out the empty new line at the bottom of the attributes list Name: Atlassian User Type: User Click Add Click the … for the schema and choose Schema settings Open the Import tab Click the Create Import button Choose External Import Set Name to my-import Click Create Import Click the … button for my-import, choose Generate new token Save in file my-import.token Get info with: curl \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --header "Authorization: Bearer $(cat ./my-import.token)" \ --silent https://api.atlassian.com/jsm/assets/v1/imports/info Using the mapping link, change the /mapping endpoint to /schema-and-mapping curl \ --silent \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --header "Authorization: Bearer $(cat ./my-import.token)" \ "$( curl \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --header "Authorization: Bearer $(cat ./my-import.token)" \ --silent \ https://api.atlassian.com/jsm/assets/v1/imports/info \ | jq -r '.links.mapping' \ | sed 's/mapping$/schema-and-mapping/')" \ | jq notice that the schema supplied does not include the Atlassian User field: { "schema": { "objectSchema": { "name": "UsersToo", "description": "", "objectTypes": [ { "externalId": "cmdb::externalId/706cfcf4-0e8a-439e-ba3b-dfe3873553bf", "name": "User", "description": "", "inheritance": false, "attributes": [ { "externalId": "cmdb::externalId/c1153fa3-35ae-4be4-9588-373b5f6d5aec", "name": "Key", "description": "", "type"...

How customers are using Confluence Agents to turn knowledge into action Since we first launched custom agents in May of 2024, we’ve seen teams use Rovo to build agents in Confluence that help them accomplish everything from turning customer feedback into PRDs to maintaining consistency across large sets of data and processes. And agents are getting even more popular, with over 5M invocations of agents every month. They take the foundation of knowledge that lives in Confluence, and act on it, saving customers over 200K hours in February alone. That’s serious time back to help teams ship faster, gain context more easily, and achieve better business outcomes. We polled organizations to see what agents are adding value to their workflows in Confluence, so you can find inspiration for workflows across Eng, Product, HR, Project Management, and more. Here are seven of our favorites: HarperCollins’s Meeting-to-Action Companion: Turns messy notes into crisp decisions, documented in Confluence and completed Jira tickets, so nothing gets lost. Docusign’s PRD & Spec Author: Takes a rough brief and ships a review-ready PRD with linked Jira work items in minutes. Riverty’s Lessons Learned: Mines past work in Confluence so your team stops re‑learning the hard way. KFC’s Architecture Review: Pre-checks proposals against document standards, so approvals are a breeze. Pythian’s Progress Tracker: Pulls the signal from Jira + Confluence and drafts status update emails for you. Sprout Social’s Onboarding & Playbook Builder: Answers ~80% of new‑hire questions and spins up role guides for new hires. Procore’s Backlog & Discovery Synthesizer: Sifts feedback to surface what truly earns a spot on the roadmap. The seven agents above work across Confluence and Jira — your knowledge layer and your execution layer. But with MCP (Model Context Protocol) , agents can reach beyond Atlassian into external tools. An agent can read knowledge in Confluence, think about it, and then take action in a third-party tool without you having to context-switch, reformat, or copy-pa...

Topic is deleted (topic deleted by author) 1 post - 1 participant Read full topic

Forge webhook `avi:jira:created:worklog` not firing when "Manage Access" restriction is enabled on issue Hi team, I have a Forge app with this trigger: trigger: key: worklog-created endpoint: worklog-created-event events: avi:jira:created:worklog Problem: When the “Manage Access” restriction feature is ENABLED on an issue, the webhook avi:jira:created:worklog does NOT fire after creating a worklog via REST API POST /rest/api/3/issue/{issueIdOrKey}/worklog . When “Manage Access” is OFF → webhook fires correctly, BUT there is a delay issue: if you log work immediately after turning OFF the feature, the webhook still does NOT fire. You need to wait ~4-5 minutes, reload the app, then log work again for the webhook to fire. Expected behavior: Webhook should fire regardless of whether “Manage Access” restriction is enabled or not, as long as the app has sufficient permissions. App permissions (manifest.yml): read:jira-work (allowImpersonation: true) write:jira-work (allowImpersonation: true) read:issue-details:jira (allowImpersonation: true) (and other relevant scopes) Question: Does “Manage Access” restriction filter/block Forge event dispatching? Is this a known limitation or a bug? Is there a workaround to receive worklog events on restricted issues? Thanks! 1 post - 1 participant Read full topic

Atlassian Teamwork Graph: The context engine behind your AI—everywhere

Advancing modern teamwork AI thinking and product news to unleash the potential of teams

Atlassian Admin APIs - Get users + their licenses Hello, We are currently using the Atlassian Admin v1 API (endpoint: https://api.atlassian.com/admin/v1/orgs/{org_id}/users ) to fetch user data such as account IDs, product access & last active information from the organization. We are also using the Atlassian Admin v2 API (endpoint: https://api.atlassian.com/admin/v2/orgs/{org_id}/directories/{directory_id}/users ) to fetch additional user data that v1 does not provide, including detailed status, platform roles & the added to org. What we are missing, however, are the app-specific roles. The current APIs only provide ‘platform-roles,’ which isn’t sufficient, as some users have specific app roles but show empty platform-roles. Additionally, none of the user APIs (including other Cloud Admin APIs and platform APIs) provide data about user licenses. Are there any available APIs for this or ways to retrieve this? 1 post - 1 participant Read full topic

Trying to perform User Impersonation with OAuth2, but I can only access public pages Hello, I’m trying to create an app that impersonates a user and can search confluence with the same permissions as that user. I followed the guides for impersonation with Oauth2, but the responses from the api don’t include items that the impersonated user should have permissions to see. I post here in the hopes someone can point me in the right direction. Implementing Oauth2 is new to me and maybe I’m missing something obvious. Context: My goal is to create a service in our company servers that searches confluence, and shows only the results that the user has permission to read. When using our company service, the user will be prompted to login to confluence, and the company app will use the token to ensure that the permissions are respected. However, after configuring all this, the app can only read pages and spaces that are marked as public I’m following these guides: OAuth 2.0 (3LO) apps / Confluence scopes for OAuth 2.0 (3LO) and Forge apps Our progress so far: We created an app (type: OAuth2 integration ) in the developer console, using the account of an admin in confluence. Get the client_ID and client_secret associated with this integration Set the scopes to “ read:content-details:confluence ”, “ read:content:confluence ”, “ search:confluence ” by adding them to the AuthorizationURL Set the callback to an URL in our company, including our internal ID in place of ${YOUR_USER_BOUND_VALUE} (let’s call it companyID ) Tried presenting this authorization URL to a user, and after they accepted, we receive the token and the companyId POST to https://auth.atlassian.com/oauth/token using the token that arrived at the callbackURL + the client_id + client_secret of our app We receive a response with access_token, scope, expires_in We check that the access_token works by calling: https://api.atlassian.com/oauth/token/accessible-resources as the guide suggests. The URL of our confluence is correct and the scopes are those requested Tried the token (as Bearer token) to GET...

Feature Request: Extend the forge tunnel timeout Context & Problem: Currently, debugging backend Forge functions is a frustrating developer experience because it’s a race against time to attach a debugger. The standard 25-second execution limit is often triggered before a developer can successfully attach the debugger, step through the code, and inspect complex logic. Proposed Solution: Introduce a way to instruct the forge tunnel command to allow for a longer timeout. This could be achieved via a new CLI flag (e.g., forge tunnel --debug-timeout 120 ) or an environment variable. Acceptance Criteria & Constraints: Local environment only: This extended timeout functionality must only apply when running forge tunnel . Strictly NO manifest changes: The standard 25-second delay is reasonable and necessary for production. This ticket should not alter the manifest or affect production execution limits in any way. Best, Mathias 4 posts - 2 participants Read full topic

Why are some modules implementation restricted to using UI kit? I am talking here about scenarios like implementing a view renderer for a custom field type module. per documentations: Rendering View mode Forge apps can provide rendering of the field with UI Kit. Custom rendering currently can't be implemented using Custom UI or Frame component. I struggle to understand why this restriction was put in place… Other modules also visible in issue view (issue context or issue panel), allow custom renderers / iframes. Plus, even custom field type allows custom renderers / iframes for edit view. UI Kit library is extremely basic. Other than using it to display static stuff, you cannot do much. Even customizing its elements is extremely limited. Supported components XCSS support is currently available on the Box and Pressable components. Supported properties Border Color Opacity Shadow Size Layout Typography Space So why this restriction? 1 post - 1 participant Read full topic

Announcing the 2026 Atlassian Impact Maker Award Winners

Introducing Flex: A Flexible Commercial Model for the AI Era

Atlassian Team ’26: Meet the AI-Native Organization

Advancing modern teamwork AI thinking and product news to unleash the potential of teams

Introducing Flex: A Flexible Commercial Model for the AI Era Introducing Flex: A Flexible Commercial Model for the AI Era Built for enterprise agility, a new value-based model helps customers keep pace with AI-driven change Atlassian will introduce Flex, a new licensing approach to help complex enterprises adopt Atlassian’s AI-powered platform with speed and flexibility amid rapidly transforming business needs. Rather than predict usage years in advance, Atlassian’s largest customers will be able to flex, adopt, and scale across Atlassian’s portfolio — ensuring their Atlassian investment keeps pace with how their teams actually work. Atlassian is developing the Flex offering in partnership with select enterprise customers. For more information, contact Atlassian . A Fixed Wallet, Flexible Adoption With more than 300,000 customers on Atlassian’s cloud platform—and over 75% of the Fortune 500 already running on Rovo—Atlassian is arming enterprises with a connected portfolio of industry-leading applications, supported by deep context and powerful AI. Atlassian is shipping new innovations weekly, from ever-increasing capabilities in Rovo, to new features in DX to measure the impact of AI investments. Customers want in; asking for more ways to adopt, scale, or redirect spend. Flex provides exactly that. With a fixed wallet they can use across the portfolio, enterprises scaling AI across their organizations can adopt any Atlassian product as their needs change and as Atlassian introduces further innovations. Customers can: Commit to a budget, flex within it: Budget owners gain flexibility and maintain predictability, without needing separate approvals every time a new team wants to adopt additional Atlassian apps or services. Consume flexibly across the platform: Organizations can easily add users, roll out new Atlassian products to different departments, and scale AI capabilities — from agentic experiences like Rovo Dev to autonomous support in Service Collection — all from the same wallet. Optimize how Atlassian spend fuels innov...

The bottleneck keeps shifting: What AI is changing about how we build Over the past few decades in the technology industry, some of the biggest constraints to building products have been about having enough engineers, time, or compute. For the first time, that era is ending. Tech teams are experiencing a revolution unlike anything they’ve seen before. The barriers to entry for building have all but disappeared. The constraint no longer comes from producing enough output, but from deciding what to build, and the restraint required to build something good. As a result, Product Managers and Designers can’t keep up with the productivity gains Engineers are making. So, the new superpower for Product Managers is discernment. This is exactly the problem Atlassian has always been in the business of solving: how do teams decide what to build, align on priorities, and turn speed into outcomes rather than chaos? In the first session of Atlassian’s new AI Talks series, Atlassian’s Chief Product and AI Officer, Tamar Yehoshua, interviewed Jon Noronha, Co-founder of Gamma , an AI-native design platform and presentation builder. Jon runs a high-growth company of just over 70 people. He shared that they’re currently at a 1:4 ratio for PMs to Engineers, where the rule of thumb has been 1:10 for decades. This is just one example of how much this shift is already underway. “If your engineers just got two or three times more productive, I don’t think the PMs did,” says Jon. “I think it’s because PMs deal with human constraints a lot more, and humans haven’t sped up to the same degree. I look at teams we have that are one PM and four engineers, and I do believe they’re getting done what a team of eight to ten engineers used to get done.” The role of a ‘builder’ in an AI-native company Across the technology industry, as companies adopt and build with AI, roles are starting to blur. The PM’s job is drifting away from coordinating developers and towards the building itself. PMs need to remove the friction between the intention of what to build and the execut...

It’s time to shatter the service quo

It’s time to shatter the service quo We’re gathered here today to lay to rest the relics of service desks past – repetitive tickets, endless queues, scattered portals. They served us faithfully, for a time. They brought order to chaos and made work visible at scale. They taught us patience. So. Much. Patience. But they couldn’t survive in the AI era. They were born at a time when the best we could do was log, route, and report. Now, in the age of AI, what got us here won’t get us where the world is going. When the work itself is happening in real time – across code deploys, SaaS apps, devices, collaboration tools – service can’t be trapped in a queue or gated behind a form. It’s time to say a grateful (relieved) goodbye, and reimagine service from the ground up – with AI, data, and teamwork at the center. Because what comes next is better. So. Much. Better. It’s time to shatter the service quo. The era of AI-native service Over the past five years, Atlassian has helped 65,000+ organizations modernize service management, proving teams move faster when dev, ops, support, and business share one platform. Now we’re applying everything we’ve learned to the AI era. We’re ushering in a new age of invisible, AI‑native service management where support and operations are no longer a department or a static process, but a living system of work that understands every team, every tool, every workflow. In this era: Context is the differentiator. Generic AI sees tickets; AI-native service sees people, tools, work, and the relationships between them – what’s broken, who’s impacted, how to fix it, and how to prevent it next time. Service happens proactively. Work doesn’t line up in a queue; it routes itself – to the right human, the right AI agent, or the right team – before anyone even has to ask. Experience is paramount. It’s not about how many tickets you closed this week. It’s about the best possible experience for your employee or customer. Teamwork evolves. Service has always been a team sport – and that team now ...

How to create a custom renderer for a jira issue default view, custom field type? I am trying to create a custom custom renderer for a jira issue view custom field type. But no luck so far. I am able to create a custom renderer for the edit mode, nut not for the standard view mode. Any idea? I want a custom field type as is the best option for my context. I am not interested in issues panels or issue context modules, as they don’t check all my requirements. I basically need a type which will allow me to define multiple similar fields which are JQL searchable, and which will be able to render a sortable/filterable table of entries. If I manage to define a default view renderer for the custom field type, I should be able to implement what I need, using this module. The view in the manifest below doesn’t have any effect on the jira default issue view: modules: jira:customFieldType: - key: typetest-configurable-validation name: typeTest description: A basic custom field with a configurable validation. type: string contextConfig: resource: main layout: basic view: resource: edit experience: - issue-view - portal-view edit: resource: edit experience: - issue-create - issue-transition - issue-view - portal-request validation: expression: value == null || !!value.match(configuration?.regexp || "^[A-Za-z]+$") errorMessage: The value is invalid resources: - key: main path: static/configurable-validation/build - key: edit path: static/edit/build permissions: content: styles: - unsafe-inline app: runtime: name: nodejs24.x memoryMB: 256 architecture: arm64 id: ari:cloud:ecosystem::app/9d40aba5-2b7d-45c3-85fc-de1ac817b655 1 post - 1 participant Read full topic

Advancing modern teamwork AI thinking and product news to unleash the potential of teams

Unable to use mcp tools Hi, I’m integrating Atlassian Rovo MCP from a custom agent (not Cursor/Claude + mcp-remote ). The MCP session authenticates with a short-lived OAuth 2.0 (3LO) access token sent as Authorization: Bearer to the Streamable HTTP endpoint. Environment MCP endpoint: https://mcp.atlassian.com/v1/mcp (env override possible via ATLASSIAN_MCP_URL ). Transport: Streamable HTTP / SSE-style MCP client (Google ADK McpToolset + StreamableHTTPConnectionParams ), not stdio / npx . Auth: OAuth 2.0 (3LO) authorization code flow; access token issued for audience api.atlassian.com . Confluence-related scopes enabled on the OAuth app (classic scopes such as read/write Confluence content, space summary, search, user, plus read:me / read:account , and offline_access where applicable). Cloud: Confluence on Atlassian Cloud (site URL of the form https:// .atlassian.net ). What works / what doesn’t I have obtained a fresh access token (recent authorization, token not expired at time of call). When the agent invokes the MCP tool getAccessibleAtlassianResources , the tool response comes back as an error with no actionable detail . Actual response (tool result) Invoking getAccessibleAtlassianResources returns structured content along these lines (identifiers from my client session): Tool name: getAccessibleAtlassianResources Response text (JSON): {"error":true,"message":"We are having trouble completing this action. Please try again shortly."} isError : true I’m not seeing a distinct HTTP status from my side beyond the MCP tool framing—the failure is surfaced as the tool’s text payload above. Expected behavior getAccessibleAtlassianResources should return the list of Atlassian Cloud resources accessible to the authenticated user (or a specific , documented error—e.g. scope, entitlement, or auth—so we can correct OAuth app configuration). What I’ve already checked New token after re-consent; same outcome on repeated tries (not only “stale session”). Same bearer token will be used for other Rovo MC...

I am developing Timesheet App for Jira I am developing Timesheet App for Jira. I need to do JSM integration where my customers end-cutoemrs sees in Jira Sevice Management detailed work-logs reports that way super-visors of my App do need to send manally MS Excel exports for end-customers that make all manual jobs unneeded and then customer save a time and time is money. I tried to do this with Visual Studio Code Copilot AI agent by Vibe-coding but Copilot do not success and tells me needed API features is missing on Forge API. Is this true or not. If true where I raise Marketplace Partner Support ticket as this API improvements to done from Atlassian side? 2 posts - 2 participants Read full topic

Our Q3 FY26 letter to shareholders

Our Q3 FY26 letter to shareholders Prefer a PDF? No worries! Get it here From the CEO Fellow shareholders, I’m thrilled to share our incredible Q3 results. The entire Atlassian team has been laser-focused on execution, and it shows in our numbers. Total revenue was strong at $1.8B, up 32% y/y Cloud revenue surged past $1.1B, with growth accelerating to 29% y/y Service Collection scaled past $1B+ in ARR, growing over 30% y/y Rovo customers are growing their ARR at 2x the rate of non-Rovo customers Rovo customers’ AI credit usage is growing 20%+ month-over-month Teamwork Collection customers use ~2x more AI credits per paid user and have 2x more agents vs. equivalent standalone customers. Our customers have more options than ever before, and they’re voting with their wallets – expanding seats across our core products and adopting additional offerings, led by Service Collection and Teamwork Collection (our primary AI monetization motion). They’re signing bigger, longer deals because the Atlassian platform is mission critical in moving their work forward. We’re seeing momentum across our three strategic priorities: Enterprise, AI, and System of Work. 1⃣ Enterprise: All up, RPO grew to $4.0 billion, an increase of 37% y/y. We continue to see strong expansion with some of the world’s largest organizations, like Siemens Energy, BBC, Rheinmetall, and Wayfair, who deepened their commitments with Atlassian this quarter. These enterprises want a trusted platform with security, governance, and domain expertise to power their workflows. 2⃣ AI : We continue to add millions of monthly active users who rely on Rovo to cut busywork and speed up their businesses. AI credit usage is growing more than 20% month-over-month, showing that customers are using Rovo for more complex, higher‑value work. Today, we see customers using Rovo growing their ARR at a rate roughly 2x the rate of those who aren’t, contributing to our strong cloud outperformance in the quarter. 3⃣ System of Work : Our strategic differentiation is contex...

Designing In Variables: How Control Panels Accelerate The Way We Design A year ago, my workflow looked very different. When a design problem opened up, I explored it by hand. Multiple screens. Multiple flows. Sometimes two or three versions of the same interaction just to compare one subtle difference. Divergent ideas spread across endless pages and files. The work helped us think, but it also created a lot of upkeep. Team critique is still one of the healthiest parts of our process. We review work together, interrogate tradeoffs, and use the tension between pros and cons to sharpen the direction. That part hasn’t changed. What has changed is the material we work in. AI prototyping is now part of my everyday toolkit at Atlassian. It helps me move faster, but speed isn’t the most important shift. The bigger change is how I think about the design work itself. At first, branching from an existing prototype felt like the answer. It made it easier to explore different directions from a shared foundation and compare them without starting over each time. But it also introduced a new kind of overhead: multiple prototypes, multiple publish links, and multiple versions to keep in sync. Now I try to start from a different place. Instead of designing fixed states first, I design variables and variations first. That shift helps me bring stakeholders in earlier, test tradeoffs sooner, and uncover unknowns before they become downstream problems. Seeing how Eduardo Sonnino, Principal Designer, AI, uses control panels in his prototypes has fundamentally changed the way I approach this work. What are control panels? A control panel is a lightweight interface built directly into a prototype. It might include toggles, sliders, checkboxes, drop downs, or radio buttons, usually tucked behind a subtle icon. Its job is simple: let you switch between scenarios and states instantly. Instead of rebuilding a screen or re-prompting an agent every time you want to explore a change, you can adjust variables live inside the prototype. The exact UI does not matter. A c...