This page includes release notes and updates for Jira Cloud app developers. Use this page to keep track of upcoming changes, deprecation notices, new features, and feature updates from Jira Cloud Platform.
For updates about changes to the Forge platform, see the Forge changelog in the Forge documentation.
Go to our developer community to ask questions. You may also be interested in the What's New blog for Atlassian Cloud where details of major changes that affect all users of the Jira Cloud products are announced.
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.
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.
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.
The Bulk fetch issues API (POST /rest/api/3/issue/bulkfetch) now supports a maximum of 1000 issues in a single request, up from the previous limit of 100. This higher limit is available for requests optimized for efficient processing. https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/1-000-Issues-One-Call-Bulk-Fetch-Gets-a-10-Boost/ba-p/3281867
What's changing
To qualify for the 1000-issue limit, your request must meet the following criteria:
Explicit field selection: You must explicitly name at least one field to include. Wildcards like *all or *navigable, and requests containing only exclusions (e.g., -description), are not eligible.
Field count: No more than 100 fields can be explicitly included.
Single-value fields only: Included fields must not return multiple values (e.g., comment, worklog, or attachment are excluded).
Restricted expands: The expand parameter must not include changelog, editmeta, operations, renderedFields, transitions, or versionedRepresentations.
What you need to do
No action is required if you wish to continue using the existing 100-issue limit. To take advantage of the 1000-issue capacity:
Update your request payload to explicitly list the specific fields you need.
Remove any multi-value fields or restricted expand parameters.
Increase your batch size up to 1000 issueIdsOrKeys.
If you require multi-valued data or changelogs for a large set of issues, we recommend splitting the work: use one 1000-issue call for "cheap" fields and separate, narrower calls for complex data. For changelogs, use the Bulk fetch changelogs endpoint to avoid the 40-item cap imposed by expand=changelog.
For more details, see the Bulk fetch issues reference documentation.
The Global Statuses Beta for team-managed spaces is now live. As previously announced, this feature allows global (site-wide) statuses to be added to team-managed workflows.
To try it, enable the feature via Jira Labs. Once enabled:
Workflow create and update APIs support global statuses in team-managed workflows.
Space templates will create workflows with global statuses by default.
Global statuses may appear in workflow read responses for team-managed spaces.
Starting September 2026, we are deprecating subscriptions on Atlassian Analytics dashboards.
What's changing
We are phasing out the ability to create and receive dashboard subscriptions in the following stages:
September 8, 2026: You will no longer be able to create new dashboard subscriptions.
November 2nd, 2026: The dashboard subscription will be fully removed for low-touch customers.
What you need to do
If you or your users rely on existing emailed dashboard reports, you should prepare for this feature's removal by November 2nd, 2026. We recommend exploring alternative ways to share data or transitioning to manual exports where available before the end-of-life date.
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.
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.
}
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.
Rate this page: