Changelog

Hello Marketplace partners,

We're excited to share that the newest improvements to Atlassian’s design language is here, as you may have seen at Team '26!

These build upon on our refreshed visual language that launched last year at Team ’25 (including colour, typography, and iconography that many of you already adopted). It makes it even easier to build modern UI that is cohesive across Atlassian and Marketplace apps, with better visual clarity and accessibility.

These improvements are being shipped as components, design tokens and guidance updates to the Atlassian Design System (ADS) and Forge UI Kit, featuring new/updated:

• Tile system and components (including objects)

• Labelling system and components (for status and categorisation)

• Shape – Border & Radius foundations

• Motion foundations

• Spotlight component

The Tile & Object system replaces inconsistent custom tile-like UI elements — previously scattered across products with mismatched sizes, radii, colours, and naming conventions. We now offer a single, coherent standard for representing tasks, pages, objects, and app icons.

Changes are coming to Avatar, Icon tile, Tile and Object packages to align with the new Tile system. The Icon object package has been deprecated and replaced by Object. Adoption details are landing soon — stay tuned.

Before/After of Tile System in Jira

We are introducing a modernised onboarding component for product tours and user engagement flows consistent with our improved design language. The new Spotlight replaces the deprecated Onboarding component.

Before: Onboarding Component

After: Spotlight Component

New design tokens for border widths and corner radii bring consistency to the shape language across Atlassian UI. Atlassian Design System components will be updated as well as the @atlaskit/tokens package.

Together, these foundations ensure components feel more unified and polished — rounded corners and border styles will follow a consistent system rather than being defined ad-hoc per component. For more information on whats to come, check out our border width and radius docs.

New radius tokens

New border width tokens

Atlassian's product ecosystem currently lacks a cohesive and standardised approach to object labelling. Each product has developed its own patterns and components for representing status, tags, verification, and classification, leading to inconsistent experiences as products become more integrated.

With our improvements to labelling we have introduced a visual uplift for the components used to label, tag, and categorise content across Atlassian apps: Lozenges, Tags, and Badges. We have also introduced a new Lozenge dropdown variant and a new Avatar tag. Please note that subtle lozenges are deprecated - replaced by tags for non status lozenges. Our aim is to create a unified, extensible labelling system that:

• Powers consistent experiences across the Atlassian ecosystem

• Supports product-specific needs while maintaining coherence

• Facilitates future innovations in work management and discovery

• Reduces implementation effort for product teams

• Reduces cognitive load for customers

This is Phase 1 of a broader labelling system that will enable consistent semantics in Phase 2.

Updated components: Badge, Lozenge, ad Tag

New components: Lozenge Dropdown and Avatar tag

Motion breathes life into every interaction and brand moment within apps, helping users understand spatial relationships, confirms their actions, and carries branded human expression across experiences. Our approach to motion introduces a systematic, shared language, enabling you to make good motion the easy default, not an exception.

With this early access release, we will be introducing semantic motion tokens and base tokens as the foundation of the system. Uplifted and new motion in key Atlassian Design System components will be coming as well as an improved motion primitive to replace legacy entering components and simplify applying entry and exit transitions in UI.

Check out our motion foundation guidelines to familiarise yourself with the upcoming changes.

Motion package before vs after

The nodejs20.x runtime for Forge apps has reached the end of its deprecation period and is no longer supported.

Starting May 6, 2026, Atlassian will progressively block the ability to deploy or update apps using the nodejs20.x runtime. Existing deployments will continue to function, but they are provided "as-is" without support or warranties. Over time, apps using unsupported runtimes may become non-functional or vulnerable to security issues.

You must update your app's to a supported Node.js runtime (nodejs22.x or higher) to continue deploying updates.

1. Edit your app’s manifest.yml file

2. Update the app.runtime.name property to nodejs22.x or nodejs24.x

3. Update your local development environment to a supported Node runtime

4. Update your Forge CLI to the latest version

5. Run npm install to update your dependencies

6. Test your app for compatibility with any breaking changes in the Node runtime

7. Deploy your app to production using forge deploy -e production

For detailed instructions, see the Node.js runtime documentation.

We are announcing the deprecation of https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-issue-glance/ (jira:issueGlance), as we have replaced with https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-issue-context/ (jira:issueContext) module. The Jira Issue Glance module will soon be removed from the work items completely.

Please refer to the following documentation for more details - https://developer.atlassian.com/cloud/jira/platform/future-proof-issue-glance-implementation/

We’ve updated Forge app upgrade behaviour for apps that add the storage:app scope to their manifest, including apps migrating from Connect to Forge.

Previously, some app versions that added storage:app could be rolled out using bulk upgrade. This behaviour changed on April 30, and is currently not supported. When a new app version adds storage:app, the upgrade requires site admin approval and can't be applied through bulk upgrade.

This behaviour applies when a new app version adds storage:app to the Forge manifest. It may affect apps adopting Forge-hosted storage, including apps migrating from Connect to Forge.

If your app already has storage:app in its manifest, this change does not affect upgrades that do not add new privileged scopes.

If you plan to add storage:app:

• release the change as a major version upgrade

• expect site admins to approve the new version

• for now - don't rely on bulk upgrade to move existing installations to that version

• consider how you will support customers who remain on the previous version until they approve the upgrade.

What’s Next

Atlassian is actively investigating restoring storage:app as a scope increase that is able to be managed by bulk upgrade

The ability to build a custom Teamwork Graph connector using Forge is now in GA. Connectors allow your app to ingest data from external tools into the Graph, associate it with Atlassian objects (for example, work items), and make the data available to customers in platform experiences like Chat, Search and Agents.

Following Forge modules - jira:customField, jira:customFieldType and jira:issuePanel can now run for unlicensed and anonymous users in Jira and Jira Service Management. This means your apps will work on publicly accessible pages and for users who don't have a full Jira and JSM license.

By default, Forge apps only run for licensed Jira and JSM users. To allow your app to serve unlicensed and anonymous users, add the unlicensedAccess property to your modules in manifest.yml.

Please refer to following guide for more details - https://developer.atlassian.com/platform/forge/access-to-forge-apps-for-unlicensed-users/#introduction.

App developers can now use the connectToForgeMigration manifest module to share their Connect to Forge migration plans and commitment status with Atlassian and their users. This experience is currently limited to developer canary tenants with private apps.

Apps with public Marketplace listings will remain unaffected. However, we encourage you to add this module to your production app, so you can receive the updated behaviour as soon as it goes live.

Please see documentation here.

Going forward, the blanket classification of all updates as major version updates is being replaced with a per-app policy based on each app's migration status.

Apps that have completed the Connect-to-Forge transition: Any app whose latest deployed version contains only Forge modules and scopes -with no remaining Atlassian Connect modules - will be re-enrolled into minor version updates once that version has been released. The proportion of the install base that has upgraded to the latest version is not a factor; what matters is that a bulk-upgrade path existed from the last version that included Connect modules to the current Forge-only version.

54 apps that already meet this criteria have been moved back to minor version updates, and we will be refreshing that list on a weekly cadence.

Apps that have not yet completed the transition: Apps that still include Connect modules in their latest deployed version will not be able to use minor version updates indefinitely. This measure protects platform stability by ensuring that API traffic from these very large apps continues to be managed through controlled rollouts rather than automatic minor-version upgrades.

Backporting changes to older major versions (temporarily restricted)
For now, you can’t publish updates to earlier major versions. This temporary restriction is in place for the same reason large apps were moved to controlled rollouts: to prevent large, high-impact changes from being automatically applied to a significant number of customers and to protect platform stability.

If you need to backport a fix to an older major version, we may be able to make an exception on a case-by-case basis. Please reach out to Atlassian with the app details, the version you need to backport to, and the rationale for the change.

As always, this policy has no effect on how apps qualify for the Forge revenue share rate. Your latest deployed app version determines revenue share eligibility.

For detailed information on how to use forge version bulk-upgrade, see https://developer.atlassian.com/platform/forge/cli-reference/version-bulk-upgrade/.

A back-end change required to safely re-enable minor version updates is in the process of being rolled out. As a result, all updates to Forge apps with over 50,000 users continue to be classified as major version updates.

Please continue to use the forge version bulk-upgrade command to roll out updates to customer sites until further notice. We expect to have this change out the door soon. Please do not rely on minor version updates until the next changelog announcement confirms that it is safe to do so.

Atlassian will discontinue support for the Atlassian Connect Express (@atlassian/atlassian-connect-express) and Atlassian Connect Spring Boot (atlassian-connect-spring-boot) frameworks alongside the end of support for the Atlassian Connect platform.

As of April 30, 2026, Atlassian has ceased development of new features for these frameworks. While we will continue to patch vulnerabilities and assess bug fixes on a case-by-case basis for the time being, this support will end completely when the Connect platform enters its final EOS phase in Q4 2026. When that happens, Atlassian will no longer:

• Investigate or remediate breaking changes caused by product or platform updates.

• Provide official maintenance or security patches for these frameworks

Both frameworks will remain available as open-source projects under the Apache 2.0 license, and their source code will continue to be accessible at:

• Atlassian Connect Express: https://bitbucket.org/atlassian/atlassian-connect-express

• Atlassian Connect Spring Boot: https://bitbucket.org/atlassian/atlassian-connect-spring-boot

Developers who wish to continue using these frameworks can fork and maintain them independently. However, any future maintenance (including addressing breaking changes or security issues that arise after Connect enters EOS) will be the responsibility of the community or individual developers.

For details on the Atlassian Connect EOS timeline and phases, see:
https://www.atlassian.com/blog/developer/announcing-connect-end-of-support-timeline-and-next-steps

The rovo:agentConnector module allows you to integrate remote AI agents hosted on external infrastructure into Jira. Once registered, users can interact with remote agents in a similar manner to other users and Rovo agents—they can be assigned work items, @mentioned in comments, and chatted with via the Rovo Chat panel.

Use this module to integrate Jira with AI agents residing outside of the Atlassian platform (such as GitHub Copilot, Cursor Background Agents, or Box AI Agents).

Following the EAP release, fullscreen viewport modals and the view.onClose() method is now generally available (GA).

You can use the fullscreen viewport for macro custom configuration modals, and for the UI Kit Modal component and Custom UI bridge Modal API in Jira and Confluence. UI Kit modal body component padding can now be toggled with hasInlinePadding prop and Custom UI bridge Modal padding has been removed.

Upgrade to the latest version of @forge/cli to start building with the fullscreen viewport and view.onClose() method.

For more information, see the documentation for the UI Kit modal, bridge modal, macro and view.onClose() method.

Starting Jul 28, 2026, Atlassian will no longer support allowlists for Statsig or LaunchDarkly tools in Runs on Atlassian (ROA) Forge apps.

This change is part of our effort to streamline feature management and ensure the security and performance of apps running on our infrastructure.

What you need to do

If your app currently relies on Statsig or LaunchDarkly allowlists, you must migrate to the native Forge feature flag capability before the deprecation date.

• Review the Forge feature flags documentation to understand how to implement native flags.

• Update your app code to use the Forge Feature Flags SDKs instead of external providers.

• Test your app in a development environment to ensure feature flag logic works as expected.

• Deploy your updated app before July 28, 2026.

We’re introducing a new Forge License REST API which lets Forge apps retrieve license information for themselves or for other apps owned by the same developer space.

Forge CLI now warns when your app uses the deprecated storage export from the @forge/api package. The new lint rule detects storage usage across common patterns, including named imports, namespace imports, and simple indirect references.

To avoid deprecation warnings and prepare for future removal of storage from @forge/api, update your apps to use the @forge/kvs package instead. Refer to our migration guide for more details.