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.
A new RFC is ready for review at: https://community.developer.atlassian.com/t/rfc-125-ui-modification-for-forge-custom-fields/98439
Jira global background scripts are now available in Preview. This feature enables you to add an invisible container that coordinates data and behavior across all pages in Jira, enabling advanced integrations and automations.
We’re releasing this feature in preview to gather feedback and help you prepare for upcoming changes. You can use global background scripts in production environments during the preview period.
For more information, see Jira global background scripts (Preview)
As announced in July 2025, a number of glyphs for the Icon component will now be removed.
The avi:jira:created:issue event now includes an clonedFrom field if the issue was created through the “Clone” operation. This field contains the ID and key of the original issue.
This fix will be rolled out on Jan 28, 2026 across all Jira Cloud instances.
We fixed bugs that caused the Issues Match REST API and webhooks to evaluate JQL queries differently than the standard Issue Navigator. JQL expressions using EMPTY or != with issue properties or the "Epic Label" field now return consistent results across all Jira Cloud features.
This fix is not backward-compatible. Integrations that relied on the previous behavior may see different results from the Match API or different events triggering webhooks.
Related tickets: JRACLOUD-96922, JRACLOUD-97120
JQL expression | Previous behavior (Match API/webhooks) | New behavior |
|---|---|---|
| Did not match issues where the field was unset | Matches issues where the field is unset |
| Matched correctly | No change |
| Did not match issues where the field was unset | Matches issues where the field is unset |
| Matched all issues, including those where the field was unset | Only matches issues where the field is set |
| Matched correctly | No change |
| Matched all issues, including those where the field was unset | Only matches issues where the field is set |
This applies to both issue properties (for example, issue.property[key].path) and the "Epic Label" field.
JQL expression | Previous behavior | New behavior |
|---|---|---|
| Returned issues where the property was never set | Only matches issues where the property exists and its value is not |
You may see differences in:
The issues returned by POST /rest/api/3/match when using JQL with EMPTY or != on issue properties or "Epic Label"
The events that trigger webhooks using JQL filters with these operators and fields
Review any JQL used in webhook filters or Match API requests that contains:
EMPTY operators with issue properties or "Epic Label"
!= comparisons with issue properties
Best practices:
Goal | Recommended JQL |
|---|---|
Check if a field is set |
|
Check if a field is not set |
|
Specific scenarios:
To find issues where a property is either not set OR has a different value:
1
issue.property[key].path != "a" OR issue.property[key].path IS EMPTYTo find issues where a property is set AND has a different value:
1
issue.property[key].path != "a" AND issue.property[key].path IS NOT EMPTYTest critical webhook flows and integrations that use the Match API to confirm they behave as expected.
We have now postponed enforcement of the new point-based rate limits for Jira and Confluence REST APIs to March 2, 2026.
What's changing
Enforcement of point-based rate limits has been postponed from February 2, 2026 to March 2, 2026.
As previously announced in CHANGE-2958, the new rate limiting system will now be enforced starting March 2, 2026.
What you need to know
No action is required at this time.
Continue to monitor the changelogs for further announcements and updates.
For more information about rate limiting, see:
We’re releasing an experimental REST API endpoint that allows you to switch workflow schemes for projects with improved performance and reliability.
POST /rest/api/3/workflowscheme/project/switch
The API accepts mapping instructions to handle updates for issues and performs asynchronous operations that leverages temporary schemes and workflows to co-ordinate updates efficiently and safely.
Enhanced performance and reliability
Support for projects with existing issues
Asynchronous processing with progress tracking
Comprehensive issue status migration handling
Requires Administer Jira global permission.
See the Switch workflow scheme for project API documentation.
We’ve added two new REST API operations that let you access historical version data for workflows in Jira Cloud. These endpoints make it easier to audit and review previous workflow versions.
You can now:
List all stored versions for a specific workflow using the List history for workflow operation.
POST /rest/api/3/workflow/history/list
Retrieve a specific workflow version from history using the Read specific workflow version operation.
POST /rest/api/3/workflow/history
Permissions required:
To access all workflows: Administer Jira global permission.
To access project-scoped workflows: Either Administer projects or View (read-only) workflow project permission.
For more information, see the API documentation for List history for workflow and Read specific workflow version.
Notes:
We only store workflow data dating back 28 days
Workflow data from before Oct 30, 2025 is not available.
The following UI Kit components are now generally available:
Comment, which displays discussions and user feedback.
Pressable, which is a primitive for building custom buttons.
CommentEditor, provides a contained comment editor UI with a simple toolbar.
ChromelessEditor, provides a simple text editor that does not have a toolbar.
For more information, see the component documentation.
To access these components, you will need to update your app to the latest version of @forge/react. In the terminal of your project directory, run:
npm install --save @forge/react@latest
New Formula custom field in Jira
We’ve started rolling out a new NumberFormulaField custom field type in team-managed spaces.
This rollout will be completed by Dec 19, 2025, excluding bundled release track customers. Support for company-managed spaces, as well as additional formula field types (TextFormulaField and DateFormulaField), will follow in the calendar year 2026.
These custom field types lets teams calculate field values based on data from Jira work items, which enables more dynamic and automated data handling within Jira.
No new APIs are required for configuring these fields; configuration is managed within the Jira application. Calculated values will be accessible via the existing API for reading field and issue data. See the Jira Cloud platform REST API documentation to know more about accessing calculated values via the API.
We are changing the way we measure rate limits across Jira and Confluence Cloud for all free and paid apps. A phased enforcement of the new rate limits will begin on February 2nd, 2026.
When the phased enforcement begins, API requests then start consuming points based on the work they perform, such as the data (objects) returned or operations triggered. Each request starts at a base point of 1 point, with additional points for each object involved.
We’re also introducing two types of app-level quotas (tiers) that apply consistently across the Atlassian platform for all apps.
It’s important to note that the vast majority of free and paid apps do not require any changes and are already operating within these limits. We’ve also reviewed usage and upgraded eligible apps to a higher tier where appropriate.
If your app requires additional capacity in the future, rest assured we will provide clear pathways to request for this. For more information, please refer to the following documentation:
Here’s how the points-based limiting works.
Points-based measurement | API requests consume points based on the work they perform, such as the data (objects) returned or operations triggered. Each request starts at a base point of 1 point, with additional points for each object involved. |
|---|---|
Two-tier quota system | Apps start in Tier 1 - Global Pool, with a shared hourly quota across all tenants. Apps with consistently high or concentrated usage may qualify for Tier-2 Per‑Tenant Pool, which provides dedicated hourly quotas per tenant. |
Points-based costs | Different objects have different point values:
|
Hourly quotas by edition | Quotas reset at the top of each UTC hour. Per-tenant pool quotas vary by customer edition and number of users. |
Here are the benefits for you:
Fairer limits, heavy operations use more quota than simple ones.
This provides more predictable API usage planning and scaling.
This gives you better visibility through detailed rate limit headers.
The vast majority of free and paid apps already operating well within the new limits.
Some updates you need to know:
Updates to the RateLimit-Reason header with new reasons:
jira-quota-global-based, which refers to the Global pool limits being breached in Jira
jira-quota-tenant-based, which refers to the Per Tenant pool limits being breached in Jira
confluence-quota-global-based, which refers to the Global pool limits being breached in Confluence
confluence-quota-tenant-based, which refers to the Per Tenant pool limits being breached in Confluence
Updates to the developer documentation regarding rate limit quotas for different tiers in both Jira and Confluence
Planned updates to the developer console to show which tier your app belongs to ahead of the enforcement
Currently, the new workflow editor is the default editing experience in Jira and is being used by the majority of customers.
Starting 26th June 2026, we will begin removing the old workflow editor for customers, which means workflows will only be editable in the new workflow editor. We ask you to please help your customers in this transition by ensuring that any workflow-related apps will work effectively with the new workflow editor.
If you encounter any issues with how your apps behave in the new workflow editor, please raise a support ticket.
Some features to be aware of to improve app experiences in the new editor:
Dynamic configuration descriptions (Forge/Connect)
Make sure to provide a unique description for configured rules.
Additional context (Forge/Connect)
Determine whether the rule is loaded in the new or old workflow editor.
Default workflow editor for user (API)
Determine whether a user has a preference set for the new or old editor.
Deep linking to statuses and transitions
Link to the new workflow editor and provide an ID with either the selectedStatus or selectedTransition query params to pre-select a status or transition.
Following the Preview release, the Forge Automation Actions is now generally available. The Automation action module allows you to extend the Automation Platform and add new Forge-based actions to your app. With this release Forge Actions can now output smart values, enabling seamless data flow and dynamic automation.
For more information, see the Forge Automation Action module documentation.
Previously, the behavior of labels in Jira was inconsistent - some experiences treated labels as case-sensitive, while others did not. To provide a more predictable and unified experience, we are making labels case-insensitive in all grouped aggregations. This means that labels differing only by letter case (for example, "Bug" and "bug") will now be treated as the same label when aggregating data.
This update will be most noticeable on Jira dashboards and in Jira Work Management (JWM). No action is required from developers.
Forge platform will be undergoing maintenance in commercial production on November 23, 2025 for approximately 1 minute between 5:30-6:30am UTC
During this interval, below capabilities will not be available intermittently:
Create/update/delete apps
Deploy apps
Install/uninstall/upgrade apps
App invocations will continue to work for existing users of the apps. However, new customers might not be able to use apps as consent process will be impacted during this interval as well.
Rate this page: