This page contains announcements and updates for developers from various products, platforms, and programs across Atlassian. It includes filter controls to make it easier to only see updates relevant to you.
To ensure you don’t miss any updates, we also provide RSS feeds. These feeds will take on any filters you applied to the page, and are a standardized way of keeping up-to-date with Atlassian changes for developers. For example, in Slack with the RSS app installed, you can type /feed <FEED URL> in any channel, and RSS updates will appear in that channel as they are posted.
As per our previous announcement, we will be progressing admin-facing migration messaging on the Connected Apps page from the Developer Canary Program to production instances. This rollout will begin in approximately two weeks.
The following app categories will receive admin-facing messaging:
Apps that have declared connectToForgeMigration with a migration intent of "no"
Apps that have declared connectToForgeMigration with a migration intent of "unsure"
Apps that have not adopted the connectToForgeMigration module
Apps without a Forge manifest (i.e., Connect apps)
Apps that have declared connectToForgeMigration with an intent of "yes" are estimated to begin receiving admin messaging in mid-August. We will provide another changelog entry at least 2 weeks before that change proceeds.
End-user messaging will not be included in this initial rollout. When ready, we'll follow the same approach:
Release to Developer Canary tenants first for early testing
Roll out in staggered cohorts
Provide at least 2 weeks advance notice via the Forge changelog before each rollout stage goes live
Adopt the connectToForgeMigration module in your Forge manifest for each major version of your app (https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-to-forge-migration-module/).
Declare your migration intent as this determines which cohort your app falls into and when messaging appears.
Provide a migration URL. This URL will be surfaced directly in customer-facing notices, replacing the default Atlassian messaging with your app-specific guidance.
Preview the experience now using the Developer Canary Program. Customer messaging is already live on canary tenants. Install your app on a canary instance, navigate to the Connected Apps page, and confirm your migration URL renders as expected before the production rollout reaches your cohort.
Apps that are blocked by an accepted Connect EOS FRGE ticket will be exempt from customer messaging until one month past the delivery date of the blocking feature. This exemption list is determined exclusively by partners who have submitted a Connect EOS Submission request on these accepted tickets, providing a valid use case and explanation. If an app utilises an affected feature but has not submitted a Connect EOS submission, it will not be exempted from this messaging.
For the full customer-facing experience (including more information on what admins will see), please visit the documentation here. This page will also be shortly updated to capture our rollout approach.
We are upgrading Jackson from version 2 to 3 in Jira 12, Confluence 11, Bitbucket 11, Bamboo 13 and Crowd 8.
The goal of this work is to keep DC products secure and compliant with our dependency policy while allowing upgrades during each major product version's supported period.
Areas affected by this upgrade:
The product system bundle provides Jackson 3 but not Jackson 2
Plugins using the system bundle's Jackson must migrate to Jackson 3. See the official Jackson 3 migration guide.
We shared the detailed migration steps in atlassian-rest UPGRADE_9_1_0.md.
If you have any comments, feel free to leave your feedback on the developer community announcement.
Support for Claude Opus 4.7 model is now available in Forge LLMs. For the exhaustive list of supported models, refer to our documentation here
Forge multi-entry resource bundles are now generally available in Jira and Confluence. This feature allows you to group multiple named entry points within a single resource, helping you optimise app performance and stay within resource limits.
What's changing
Multi-entry resource bundles allow you to define multiple entry points for a single resource in your Forge manifest. This is particularly useful for complex apps that need to share code between different parts of the UI while keeping the overall bundle size manageable.
What you need to do
To get started with multi-entry resource bundles, you can update your manifest.yml to include multiple entry points under a single resource. For more details, see the documentation here.
Note: This feature is not yet supported in Atlassian Government Cloud.
From Jul 8, 2026, we will begin removing the temporary restriction announced in CHANGE-3109 that required every update to Connect to Forge apps with over 50,000 users to be classified as a major version update. We will contact partners first before lifting the restriction on their app(s).
This restriction was introduced as a temporary safety measure to protect downstream Forge services from sudden traffic spikes during large version migrations. Since then, we have completed significant scaling and reliability work across the affected services, so we are now able to return these apps to the normal minor version update path.
Affected Forge apps can return to using minor version updates, rather than being forced into major version updates and forge version bulk-upgrade batches.
You will still be able to use forge version bulk-upgrade if you prefer a controlled, batched rollout - this remains available and unchanged.
For detailed information on how to use forge version bulk-upgrade, see https://developer.atlassian.com/platform/forge/cli-reference/version-bulk-upgrade/.
To avoid any unexpected impact on in-flight migration activities, we will not automatically re-enable minor version updates for every affected app at once. Instead:
We will contact affected partners individually to confirm whether you would like minor version updates re-enabled for your app, and to coordinate timing against your current migration plans.
If you would like the restriction removed for your app now, please reach out to Ecosystem Support, and we will action the request.
Additional fields available in Bitbucket Forge events. This change is backward-compatible; no existing fields are removed or renamed.
What’s changing:
Bitbucket Forge events now include additional fields in their payloads. This update allows Forge apps to access more comprehensive data directly from the event, reducing the need to make separate API calls back to Bitbucket to fetch missing details.
The following event types are updated with additional fields:
Repository created events
Repository push events
Build status events
Pull request events
What you need to do:
No action is required. If your app is already listening to these Bitbucket Forge events, the additional fields will automatically be available in the event payload. If you validate event payloads with a strict schema, ensure your validator allows additional properties.
You can review the updated payload structures in the Bitbucket events reference documentation.
What's changing
You can now control access for the jira:uiModifications module for different user types:
Anonymous – users who are not logged in
Unlicensed – users invited to a Jira space without a license (guests in case of Jira)
Customer – JSM portal customers
By default, Forge apps only run for licensed Jira and Jira Service Management users. With this update, you can allow your UI Modifications app to run for anonymous, unlicensed, or customer users by declaring it in your app manifest.
As previously announced, from Jun 29, 2026, UI Modifications will not run for anonymous, unlicensed or customer account users unless the module explicitly declares support for these user types in the Forge app manifest.
What you need to do
To allow your app to work for anonymous, unlicensed, or customer users, add the unlicensedAccess property to the jira:uiModifications module in your manifest.yml file.
1
2
3
4
5
6
7
8
9
10
11
modules:
jira:uiModifications:
- key: ui-modifications-app
title: UI modifications
resource: uiModifications
resolver:
function: resolver
unlicensedAccess:
- anonymous
- unlicensed
- customerOnly include the user types your app needs. For example, if your app only needs to work for anonymous users:
1
2
unlicensedAccess:
- anonymousFor detailed steps, refer to the https://developer.atlassian.com/platform/forge/access-to-forge-apps-for-unlicensed-users/.
What’s changing?
In preparation for the upcoming Developer Preview release of Forge Containers, access to the early access program (EAP) for this capability is now closed.
We want to thank everyone who participated in the EAP and provided valuable feedback. Your insights have been instrumental in shaping the next phase of Forge Containers.
What you need to do
If you are currently participating in the EAP, you can continue to use the feature.
If you missed the EAP, stay tuned to this changelog for the Developer Preview release announcement to start building with Forge Containers.
Forge apps that run entirely in the browser — with no backend resolver — can now emit custom metrics directly from the frontend. Previously, custom metrics were only available to apps with a server-side resolver.
What's new
Frontend custom metrics — counter metrics can now be emitted from your app's browser-side code using the frontendCustomMetrics SDK in @forge/bridge available from v6.0.0 onwards.
Metric limit doubled — to accommodate both backend and frontend metrics on the same app, the per-app custom metric limit has increased from 10 to 20.
Documentation
See Instrument a frontend custom metric for the full API reference and setup guide.
We recently introduced two new Users and Groups REST APIs that are available to all customers. These APIs replace two existing REST APIs, which we’re removing in June 2027.
The following APIs will stop working after June 30, 2027:
Users
Get users in an organization: GET/v2/orgs/{orgId}/directories/{directoryId}/users
Groups
Get groups in an organization: GET/v2/orgs/{orgId}/directories/{directoryId}/groups
We recommend you update your workflows to the new APIs as soon as possible to avoid any disruption.
What’s changing?
As previously announced in CHANGE-3120, usage of asynchronous Forge functions is now billed in line with Forge platform pricing.
Billing will be enabled progressively for all apps commencing Jul 2, 2026, with charges commencing in invoices issued from Aug 1, 2026 onwards.
Roll-out complete
The progressive roll-out of these changes is now complete.
What do I need to do?
No action is required. However, you should review your forecast usage in the Usage and Charges section of the Forge developer console.
We’re introducing two new Users and Groups APIs available to all customers:
Search for users in an organization (v2)
Return a page of users in an organization that match the supplied parameters.
Search for groups in an organization (v2)
Return a page of groups in an organization that match the supplied parameters.
These APIs are provided to replace some recently deprecated APIs.
Use Search for users in an organization (v2) instead of:
Use Search for groups in an organization (v2) instead of:
Forge Rolling Releases is now available in Preview. This feature allows app developers to continuously deploy code updates to all eligible installations, even when new permissions are involved.
Getting started:
Add enforcement: app-managed to your manifest's permissions section
Implement the Permissions SDK to check permissions at runtime
Run forge deploy: a rollout will start automatically, or use --no-rollout and manage rollouts from the Developer Console
The new rollouts tab in the developer console is progressively rolling out over the coming days. If you don't see it yet, check back shortly as access is being expanded incrementally.
For full details, see https://developer.atlassian.com/platform/forge/rolling-releases/.
This is a Preview release of the Atlassian Rovo MCP v2. This endpoint is considered early access and will be subject to change; including the MCP tools and their responses.
We’re excited to share that a preview release of our new Atlassian Rovo MCP is now available for early access. This release introduces some significant changes including:
Dozens of new tools abstracted behind discover and execute tools
New and improved Confluence tools, introducing support for attachments, whiteboards, databases and more.
Reduced default tool exposure, reducing context window consumption by >50%
Optimised tool responses, substantially reducing context window consumption from tool invocations
The preview endpoint is now available at https://mcp.atlassian.com/v1/mcp/preview and can be utilised today.
The new customerServiceManagement:crmImport Forge module is generally available from June 30, 2026.
What's changing
This module allows you to add an item under the Manage dropdown on the Customers, Organizations, and Products pages within the customer directory of the Customer Service Management (CSM) app. When a user clicks the item, your app renders content inside a modal dialog.
This extension point is specifically designed for apps that import customer context data from external CRM systems into Customer Service Management, providing a dedicated UI entry point for these integrations.
What you need to do
To start using this module, refer to the customerServiceManagement:crmImport manifest reference for technical configuration and schema details.
Rate this page: