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.
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/
The deprecated shape prop and UNSAFE_circleReplacementComponent prop have been removed from IconTile in @atlaskit/icon. Circular icon tiles are no longer supported. This follows the deprecation notice issued 6+ months ago.
shape prop - shape="circle" and shape="square" are no longer accepted. Square is the only shape and is now the default with no prop needed.
UNSAFE_circleReplacementComponent prop - the escape hatch introduced during the deprecation period has been removed.
If you used shape="square" - simply remove the prop. No visual change:
1
2
- <IconTile icon={MyIcon} label="" appearance="gray" size="medium" shape="square" />
+ <IconTile icon={MyIcon} label="" appearance="gray" size="medium" />
If you used shape="circle" with UNSAFE_circleReplacementComponent - the replacement component you were already providing is now rendered directly. Remove the IconTile wrapper and render your replacement directly:
1
2
3
4
5
6
7
8
9
10
11
- <IconTile
- icon={MyIcon}
- label=""
- appearance="gray"
- shape="circle"
- size="small"
- UNSAFE_circleReplacementComponent={<Box xcss={myCircleStyles}><MyIcon label="" /></Box>}
- />
+ <Box xcss={myCircleStyles}>
+ <MyIcon label="" />
+ </Box>
If you used shape="circle" without a replacement component - use ADS primitives to recreate a circular appearance:
1
2
3
4
- <IconTile icon={MyIcon} label="" appearance="gray" shape="circle" size="small" />
+ <Box xcss={xcss({ borderRadius: 'border.radius.circle', backgroundColor: 'color.background.neutral' })}>
+ <MyIcon label="" color={token('color.icon.subtle')} />
+ </Box>Bitbucket Data Center and Server 9.4.22 and 10.2.5 bug fix releases are available now!
To see the issues resolved in these bug fix releases, go to:
Point-to-Point logs export is now available in Early Access (EAP). This feature allows Atlassian to push Forge app logs directly to your preferred logging tool across all environments, including production.
During this EAP, we support the following tools:
Datadog
Sumo Logic
Amazon CloudWatch (US region only)
Splunk
What you need to do
Review the setup guide to understand how to share your tool details with us in the EAP form.
As per the notice of the deprecation of the workflow transition properties APIs on March 30, 2025, the Workflow transition properties API set has been removed from our public API. This API is no longer supported.
If you were using the Workflow transition properties APIs, you must transition to the Bulk get workflows and the Bulk update workflows APIs to manage transition properties on workflows.
What's changing
Forge apps can now provide custom search suggestions for searchAlias properties of Forge object custom fields.
If your app already uses searchSuggestions, you can enable it for a specific alias by setting searchSuggestionsEnabled: true on the object schema property that defines that searchAlias. When users write JQL against that alias, Jira will show app-provided suggestions instead of default indexed values.
What you need to do
If your Forge object custom field already uses searchSuggestions and you want those suggestions to apply to a searchAlias:
Update your app's manifest to set searchSuggestionsEnabled: true on the schema property that defines the alias.
Ensure your searchSuggestions function is configured to handle requests for the alias.
No action is needed if your app doesn’t use search aliases, or if you want aliases to keep using Jira’s default autocomplete.
For more information, consult the https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field reference documentation.
Callers can now have up to 10 unfinished tasks queued up, increasing the limit from the existing 5.
API callers can now have up to 10 unfinished tasks. See https://developer.atlassian.com/cloud/customer-service-management/bulk-apis/#key-concepts to understand key concepts regarding visibility on tasks.
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.
Rate this page: