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.
What's changing
Branch restrictions now support adding the following to Write Access and Merge Access branch permissions in your branch restriction rules:
Repository access tokens (RAT)
Project access tokens (PAT)
Workspace access tokens (WAT)
Forge apps
Rovo Dev
This applies to both repository and project-level branch restrictions.
What you need to do
No action is required. To use this feature, navigate to Repository settings → Branch restrictions or Project settings → Branch restrictions and add your access tokens, Forge apps or Rovo Dev to the desired permission rules.
For more information see our community post.
You can now copy a workflow using the Jira Cloud platform REST API. The new copy workflow endpoint creates a new workflow from an existing one, together with the statuses that workflow uses:
POST /rest/api/3/workflows/copy
Previously, copying a workflow was only possible through the UI.
The copy is created in the same scope as the workflow it was copied from. Copying a global workflow produces a global workflow, and copying a project-scoped workflow produces a workflow scoped to the same project.
Permissions required
Administer Jira global permission to copy any workflow, including project-scoped workflows.
To copy a project-scoped workflow, either the Edit workflows project permission, or both the View (read-only) workflow and Administer projects project permissions.
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-146-conditional-execution-for-jira-workflow-post-functions/102673/1
We’ve updated the Forge CLI to improve support for automation and machine-parsable workflows. Errors and warnings are now directed to stderr, ensuring that stdout remains clean for parsing structured data.
Additionally, we’ve added --json support to the following commands:
forge environments list
forge repositories list
forge repositories images list
forge webtrigger list
forge storage entities indexes list
Update to the latest version of the Forge CLI by running: npm install -g @forge/cli@latest.
If you use these commands in scripts or automation, you can now append the --json flag to recieve structured output. Ensure your scripts are configured to capture errors from stderr.
We are introducing RFC-145, which proposes a new set of asynchronous bulk mutation APIs for the Jira Cloud REST API. These APIs are designed to handle large-scale data operations more efficiently by processing requests asynchronously, reducing the risk of timeouts and improving overall system stability for high-volume updates.
What's changing
The proposed RFC introduces a consistent pattern for bulk mutation operations in Jira Cloud:
Asynchronous processing: Instead of waiting for a synchronous response, you will receive a job ID to track the progress of your bulk request.
New bulk endpoints: The RFC covers asynchronous versions of common mutation tasks, such as bulk issue updates and deletions.
Status polling: A new set of endpoints will allow you to poll for the status of an ongoing bulk job and retrieve the final results once completed.
What you need to do
This is currently an RFC (Request for Comments) and is open for feedback from the developer community.
Review the full proposal on the [Atlassian Developer Community] (https://community.developer.atlassian.com/t/rfc-145-jira-cloud-rest-api-async-bulk-mutation-apis/102577).
Provide your feedback, use cases, or concerns directly in the community post to help shape the final implementation.
Stay tuned for further updates regarding the Early Access Program (EAP) and official rollout dates.
When using Jira’s List or Global Search views, you could toggle between the List and detail view. The new defaults for opening work items will be in a resizable preview (side) panel, or in a modal.
What you need to do
Review your apps: If you own apps related to the Detail view, ensure they'll work with the new work item view modalities.
Test and report issues: If you encounter any behavior issues with the new preview panel or modal, please raise a support ticket.
For more details, refer to the community announcement.
The Forge platform will undergo maintenance in FedRAMP production on 13 September 2026 between 23:00 UTC and 00:00 UTC on 14 September.
There may be up to 30 seconds of write-operation downtime within this maintenance window. During that time, creating, updating, deleting, deploying, installing, uninstalling, or upgrading apps, and granting or revoking app access and consent, may be intermittently unavailable.
Existing app invocations will continue to work. Users should retry a failed write operation after maintenance completes.
What's changing
Apps adopting Forge from Connect can now use the migratedFrom property in a Forge macro module to map one or more existing Connect macro keys to a single target Forge macro. This allows you to consolidate multiple legacy macros into a new Forge implementation.
Key details of this feature:
Resolution: Existing Confluence content that uses any of the listed Connect macro keys will automatically resolve to the target Forge macro.
Scope: The listed keys must belong to the Connect app declared in the app.connect.key field of your manifest.
Responsibility: The target Forge macro is responsible for handling the configuration and parameters stored by the previous Connect macros. Note that migratedFrom does not transform parameter schemas.
Exclusivity: A legacy macro key can be claimed by only one Forge macro on a given tenant.
Current limitation: Forge-to-Forge macro consolidation is not currently supported; this property only supports mapping Connect macro keys to Forge macros.
What you need to do
To consolidate your Connect macros, update your manifest.yml file to include the migratedFrom property under the target macro module:
1
2
3
4
5
6
modules:
confluence:macro:
- key: consolidated-macro
migratedFrom:
- old-connect-macro-a
- old-connect-macro-bFor more information on migrating macros and handling legacy data, refer to the Adopting Forge from Connect: Migrate macros documentation.
By mapping legacy Connect macro keys to a Forge macro, migratedFrom helps existing Confluence content continue to resolve correctly during the app-user migration to Forge. For background, see CONFCLOUD-84508.
Bitbucket pull request (PR) update events for Forge apps now feature an additional changes field in their payloads. This field is present when a PR is updated due to a new commit being pushed to the source branch.
This update allows Forge apps to distinguish between code-level updates (new commits) and metadata updates (such as changes to the title or description). This is a backward-compatible change; no existing fields have been removed or renamed.
What you need to do
For most apps, no action is required. If your app is already listening to Bitbucket PR update events, the additional field will automatically be available in the event payload.
However, if you validate event payloads with a strict schema, ensure your validator is updated to allow the new changes property. You can review the updated payload structures in the Bitbucket pull request updated event reference documentation.
What’s changing
The new rovo:skill module allows you to package reusable, task-specific instructions and supporting reference files within your Forge app. You can add these skills to Forge Rovo agents through the app manifest.
Key features include:
Tool orchestration: Skills can declare Forge action modules as tool dependencies, allowing them to coordinate multiple actions into a complete workflow.
Rovo Studio integration: Forge Rovo skills will also be available to custom agents in Rovo Studio. This capability will roll out progressively over the week following this announcement.
Dynamic selection: At runtime, an agent selects a skill based on its description and the user’s request.
During the EAP, the following limitations apply:
Apps that declare rovo:skill can only be deployed to development environments.
Skill-to-skill dependencies are not supported.
Executable skill sources, including scripts, are not supported.
A skill directory must not exceed 100 MB uncompressed.
Tool dependencies must be action modules declared by the same app.
What you need to do
Sign up for the Forge Rovo skills EAP.
Review the rovo:skill module reference to learn how to define skills in your manifest.
For guidance on choosing between prompts, skills, and actions, see the rovo:agent module reference.
As per our previous announcement, admin-facing Connect end-of-support (EOS) migration messaging on the Connected Apps page is now gradually rolling out to production instances for apps that have declared a migration intent of ‘yes’.
Apps that have declared connectToForgeMigration with a migration intent of "yes"
The following app categories have already been rolled out to receive admin-facing messaging as per our previous changelog:
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)
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.
Exemptions
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’re excited to share that a new version of Atlassian Rovo MCP is now available. This release introduces some significant changes including:
Support for new products - Loom, Goals, Projects, Team, Focus, Talent and Bitbucket.
New and improved Jira and Confluence tools, introducing support for attachments, whiteboards, databases, sprints and more.
More details about new and available tools are available here.
The new Atlassian Rovo MCP endpoint is now available at https://mcp.atlassian.com/v2/mcp and can be utilised today. Existing plugins and connectors on third-party platforms are being updated and may require you to re-add the plugin/connector for some clients.
On Mar 1, 2027 any existing utilization of v1 will automatically start to expose and utilize v2 tools. Any incompatible clients will need to clear cached clientIds or .well-known credentials to support continued authentication.
Customers utilising MCP Gateways can expose a flat list of tools by utilising the https://mcp.atlassian.com/v2/mcp?tools=all endpoint. tools/list will return tools paginated as 50 tools per page.
Bitbucket Data Center and Server 9.4.24, 10.2.7 and 10.4.3 bug fix releases are available now!
To see the issues resolved in these bug fix releases, go to:
In https://developer.atlassian.com/changelog/#CHANGE-3253, we announced that Forge custom fields (FCF) of type object can now render a rich custom edit experience in Jira's bulk edit. At that time, issue and project details were not available in the extension context during issue-bulk-edit, and we recommended using renderContext === 'issue-bulk-edit' to detect this case and render a fallback UI.
This limitation has now been removed. Issue and project context is now available in your app's extension context during bulk edit. You can use this context to make more informed decisions about the UI or the options you display.
If you previously added a fallback UI for the issue-bulk-edit render context, you can now update your app to use the available issue and project context instead.
Review the updated https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field/#extension-data:~:text=module%20is%20rendered.-,issues,-issue%5B%5D for details on the context shape.
No action is required if your edit experience does not depend on issue or project context.
Forge Frontend logging is now available in Early Access Program (EAP). This feature is supported for both UI Kit and Custom UI across all environments, including production. It captures console.error, uncaught exceptions, and unhandled promise rejections.
What's changing
Direct frontend observability: You can now view platform logs, custom log errors, and exceptions from your app's frontend directly in the Forge Developer Console and CLI.
Log export support: Frontend logs are accessible via the Export app logs API and Point to Point Logs Export.
Customer-controlled logging: Frontend logs are accessible when customers have provided consent to share app logs in admin.atlassian.com.
No billing during EAP: Frontend logs generated during the EAP period will not be charged.
What you need to do
Sign up for the EAP: Submit a request via the EAP form to enable this capability for your apps.
Rate this page: