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 set custom colors for UI Kit Visualisation charts. You can either set a color theme or assign colors to attributes. This can be done by passing the prop colorPalette into your chart.
For an example of how to implement this, please see the Forge UI Kit example app at https://bitbucket.org/atlassian/ui-kit-charts-example/src/master/.
For more information, see documentation.
We’re simplifying how fields are associated and configured in Jira by introducing field schemes, a new model that will replace field configurations and field configuration schemes. This change also affects how field contexts will be used for visibility.
Field schemes will become the source of truth of what work types a field can appear on for Spaces.
Field contexts define the default values for fields and the options that are available for users to select. Given contexts will no longer be used to restrict where fields are available, every field will have a global context which is always present and cannot be deleted.
Screens, Screen schemes and Work item layouts determine what users see when they are creating or viewing a work item in the full page view.
This will involve the following changes:
Component | Update | Date |
|---|---|---|
New field associations | Open Beta (sign up here) | February 2026 |
GA | April 2026 | |
removed (see More details for complete list of APIs) | July 2026 | |
All unused fields from schemes | removed (to improve Jira’s performance) | July 2026 |
For more context, please review the announcement blog post and related RFCs.
To determine or manage a fields availability we recommend using APIs that support both field configurations and the future field schemes, namely:
Get fields for projects NEW (see RFC-104)
Field schemes NEW (see RFC-105)
The following API changes will be implemented on Feb 2026 for beta customers, April 2026 for GA:
Delete custom field context: will no longer support removing global contexts.
Add issue types to context: will no longer support restricting the global context to certain issue types.
Assign custom field context to projects: will no longer support restricting the global context to certain projects.
To assign a context with specific projects or issue types we recommend creating a new context, rather than modifying the global context.
Create project: changes to template format (see RFC-121).
All Field configuration APIs will be removed on July 2026:
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.
Rate this page: