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
As of JCMA 1.14.0, the mappings exporter is in preview and available for customer migrations.
The mappings exporter generates a mapping file during the migration process. This allows your cloud app to download all necessary mappings in a single API call, rather than constructing them through multiple individual mapping API requests.
This preview release also introduces support for:
Connect apps
Migration reruns
Triggering app migrations
Entity type filtering, allowing you to receive only the specific mappings your app requires
What you need to do
To begin testing the mappings exporter or to enable it for your customers, contact Atlassian via the app migration support channel.
Review the simplified app migration documentation for implementation details.
Refer to the mapping file specification for details on the file format and structure.
Starting mid-August, we are introducing a Beta feature that allows global (site-wide) statuses to be added to team-managed workflows. This change enables better status consistency across team-managed spaces.
As part of this update, the workflow create and update APIs for team-managed workflows will support the addition of global statuses. Additionally, space templates will create workflows with global statuses by default when the beta feature is enabled As a result, you can expect to see global statuses in workflow read responses for team-managed spaces.
API shapes remain the same. The feature will be opt-in (via Jira Labs) and will become the default in future releases. No immediate action is required for existing integrations.
As per our previous announcement, admin-facing Connect end-of-support (EOS) migration messaging on the Connected Apps page is now rolling out to production instances. This messaging, which was previously limited to Developer Canary tenants, is being deployed in staggered cohorts.
The following app categories will begin receiving admin-facing messaging in production:
Apps that have declared connectToForgeMigration with a migration intent of NO
Apps that have declared connectToForgeMigration with a migration intent of UNDECIDED
Apps that have not adopted the connectToForgeMigration module
Apps without a Forge manifest (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.
What you need to do
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/) if you have not already.
Declare your migration intent - 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.
For details about the full customer-facing experience, see What admins see on the Connected Apps page.
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 and applies to only the apps that have been marked as affected by the feature in the submission. If an app utilises an affected feature but has not submitted a Connect EOS submission, it will not be exempted from this messaging.
End-user messaging is not included in this rollout. When available, we will follow the same approach of releasing to Developer Canary tenants first for partner testing, roll out in staggered cohorts, and provide at least 2 weeks advance notice via this changelog before each stage goes live.
Preview feature: The App Migration Platform will now allow apps to access restricted spaces in confluence associated with the migration.
Bitbucket Data Center 10.4 is available for upgrade!
Get the most out of handy features, such as changing pull request authors, reverting pull requests from a merged PR, and fine grained pull request email notification control!
Marketplace Partners can now provide Privacy and Security information specific to their Atlassian Government Cloud and Isolated Cloud app versions.
What’s changing
If your app is available in Atlassian Government Cloud or Isolated Cloud, you can now complete a dedicated Privacy and Security tab for each environment. This allows you to provide information that accurately reflects how your app handles data, permissions, hosting, and compliance within these specific environments.
To simplify the process, you can use the Copy from Cloud feature to pre-populate fields from your existing cloud app listing.
What you need to do
Log in to the Marketplace vendor console.
Navigate to the Privacy and Security tab for your Atlassian Government Cloud or Isolated Cloud app listing.
If applicable, use Copy from Cloud to jumpstart your entry
Review and complete all required fields, including data handling, operational controls, and support details.
Save and submit your changes.
For more information, see the following resources:
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-140-updating-categories-in-the-editors-element-browser/101855
Support for Claude Opus 4.8 model is now available in Forge LLMs. For the exhaustive list of supported models, refer to our documentation here
We are deprecating the workflowId field in the webhook payloads sent to Connect workflow Post Functions. This field now returns a placeholder value, and will be removed after 31 July 2027.
The workflowId is an invalid value and may lead to bugs in your applications if used. It references an internal identifier that does not correspond to a workflow and cannot be mapped to any workflow in our public APIs.
If you are using workflowId, you should instead use workflowName or workflowEntityId, both of which contain values that can be used to correctly identify workflows.
What's changing
The workflowId field in webhook payloads triggered from Connect workflow Post Functions now returns a placeholder value. The field will remain in the payload until it is removed after 31 July 2027, but its value should not be relied upon.
Why
The workflowId value references an internal identifier that does not correspond to a workflow. It cannot be used to query or identify workflows through our public APIs, and using it can cause unexpected behaviour or bugs in your app.
What you need to do
Before 31 July 2027:
• Identify any integrations that read workflowId from these webhook payloads.
• Replace usages of workflowId with workflowName or workflowEntityId.
See example connect trigger below:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
"configuration": {
"value": "Configuration from the post function edit page"
},
"issue": {
"fields": {
...
},
"id": "10000",
"key": "TEST-1",
"self": "http://issues.example.com/jira/issue/10000"
},
"transition": {
"from_status": "Open",
"to_status": "Resolved",
"transitionId": 5,
"transitionName": "Resolve Issue",
"workflowId": 99999, <-- deprecated, no longer used.
"workflowName": "example workflow"
"workflowEntityId": "<some UUID>" <-- newly added, should be used.
}
}
We are deprecating the workflowId field in the webhook payloads sent via the Trigger a webhook post function in Jira workflows. This field now returns a placeholder value, and will be removed after 31 July 2027.
The workflowId is an invalid value and may lead to bugs in your webhook handlers if used. It references an internal identifier that does not correspond to a workflow and cannot be mapped to any workflow in our public APIs.
If you are using workflowId, you should instead use workflowName or workflowEntityId, which contains a value that can be used to correctly identify workflows.
What's changing
The workflowId field in webhook payloads sent via the Trigger a webhook post function now returns a placeholder value. The field will remain in the payload until it is removed after 31 July 2027, but its value should not be relied upon.
Why
The workflowId value references an internal identifier that does not correspond to a workflow. It cannot be used to query or identify workflows through our public APIs, and using it can cause unexpected behaviour or bugs in your webhook handlers.
What you need to do
Before 31 July 2027:
• Identify any integrations that read workflowId from these webhook payloads.
• Replace usages of workflowId with workflowEntityId.
See the example shape of a webhook below (or read the relevant documentation here: https://developer.atlassian.com/cloud/jira/platform/webhooks/#webhook-payload )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
"timestamp": 1606480436302,
"webhookEvent": "jira:issue_updated",
"issue_event_type_name": "issue_generic"
"user": {
...
},
"issue": {
--> See Issue shape in table below
},
"transition" : {
"from_status": "Open",
"to_status": "Resolved",
"transitionId": 5,
"transitionName": "Resolve Issue",
"workflowName": "example workflow"
"workflowId": 99999, --> this is now a placeholder value
"workflowEntityId": "<some UUID>" <-- newly added, should be used.
}
We’re adding the workflowEntityId to webhook payloads sent to Connect applications to trigger post functions - this ID can be used to perform workflow operations or query data using the Workflow Rest APIs
The transition object will now contain a entry for the workflowEntityId.
See example below:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
"configuration": {
"value": "Configuration from the post function edit page"
},
"issue": {
"fields": {
...
},
"id": "10000",
"key": "TEST-1",
"self": "http://issues.example.com/jira/issue/10000"
},
"transition": {
"from_status": "Open",
"to_status": "Resolved",
"transitionId": 5,
"transitionName": "Resolve Issue",
"workflowId": 99999, <-- deprecated, no longer used.
"workflowName": "example workflow"
"workflowEntityId": "<some UUID>" <-- newly added, should be used.
}
}
We’re adding the workflowEntityId to webhook payloads that are sent as part of workflow post function execution - this ID can be used to perform workflow operations or query data using the Workflow Rest APIs
The transition object will now contain the workflowEntityId field.
See the example shape of a webhook below (or read the relevant documentation here: https://developer.atlassian.com/cloud/jira/platform/webhooks/#webhook-payload )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
"timestamp": 1606480436302,
"webhookEvent": "jira:issue_updated",
"issue_event_type_name": "issue_generic"
"user": {
...
},
"issue": {
--> See Issue shape in table below
},
"transition" : {
"from_status": "Open",
"to_status": "Resolved",
"transitionId": 5,
"transitionName": "Resolve Issue",
"workflowName": "example workflow"
"workflowId": 99999, --> this is now a dummy unusable value
"workflowEntityId": "<some UUID>" <-- newly added, should be used.
}
The @atlaskit/icon-object package has been permanently removed from our internal code and is no longer supported, please use @atlaskit/object package instead.
The Object component is an icon that represents an Atlassian-specific content type, with consistent color and styling that stays in sync with the Atlassian Design System. For cases where you need the object icon presented inside a rounded container (for example, to represent a noun in a list or card), use the accompanying Object tile component, which pairs the object icon with a tile using the correct background and sizing.
What you need to do if you are using Forge Custom UI:
If your app still imports from @atlaskit/icon-object, migrate to @atlaskit/object. See the Object explorer for the full set of object types, sizing, and styling options, and the Object tile explorer for displaying objects within tiles.
Support for Claude Sonnet 5 model is now available in Forge LLMs. For the exhaustive list of supported models, refer to our documentation here
Commerce Pricing APIs are currently unavailable.
Access to the Commerce Pricing APIs (both update and fetch operations) has been temporarily blocked while we carry out maintenance and validation work. Please do not use these APIs until further notice. Any requests made during this period will fail and return an API block message. We'll update this page and publish a changelog entry once the APIs are available again. Thank you for your patience.
https://developer.atlassian.com/platform/marketplace/marketplace-app-pricing-api/
Rate this page: