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 Software Cloud.
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.
We’ve added a new rovo.isEnabled method to the Forge UI bridge API. This method returns a boolean indicating whether Rovo is enabled for the tenant. You can use it alongside the existing rovo.open method to conditionally invoke Rovo only when it’s available.
For more information, see the updated documentation for the Rovo bridge methods.
We've added optional height and width properties to the Frame component in UI Kit. Apps can now set explicit dimensions in pixels or percentages, instead of relying on automatic resizing. This gives you more control over your app's layout.
For more information, see the updated documentation for the Frame component.
Rollout : progressive rollout by tenant. IN PROGRESS
We've updated the behavior of the Create work type API. Previously, creating a work type automatically added it to the Default Work Type Scheme. This is no longer the case.
What's changing
Creating a work type no longer automatically associates it with the Default Work Type Scheme
You must explicitly associate work types to work type schemes using the Associate work type to a work type scheme API
What you need to do
If your integration relies on newly created work types being automatically available in the Default Work Type Scheme, update your code to explicitly associate work types after creation:
Create the work type using the Create work type API
Associate the work type to the desired work type scheme using the Associate work type to a work type scheme API
This change is not backward-compatible. Integrations that relied on automatic association may need updates to ensure work types are properly associated with schemes.
For more information, see:
Work types in the Jira Platform REST API documentation
Work type schemes in the Jira Platform REST API documentation
Community post: Project fields association improvements for additional context
Related: CHANGE-2527 (deprecation notice)
Rollout : IN PROGRESS
This change log ticket is a followup to https://ecosystem.atlassian.net/browse/CHANGE-2527 (where we announced a deprecation whereby all new fields now needed to be added to projects explicitly when created via API).
Change | Date |
|---|---|
All new fields will need to be added to projects explicitly when created via API (more details) | Feb 9, 2026- Feb 12, 2026 |
Create custom field: will no longer implicitly associate the field with all projects. It needs to be associated with the required contexts using the Create associations API.
Rollout : progressive rollout by tenant. IN PROGRESS
We've updated the behavior of the Delete work type scheme API. Previously, you could delete work type schemes even when they were associated with projects. This is no longer allowed.
What's changing
Work type schemes that are associated with one or more projects can no longer be deleted
The Delete work type scheme API will return a validation error if you attempt to delete a scheme that is associated with projects
What you need to do
If you need to delete a work type scheme that is currently associated with projects, you must first reassign all projects to a different scheme:
Use the Get work type scheme API with the projects expand and id query parameter to get a list of projects associated with the scheme you want to delete
Use the Assign work type scheme to a project API to reassign all associated projects to another work type scheme
Once all projects have been reassigned, you can delete the unused scheme using the Delete work type scheme API
This change is not backward-compatible. Integrations that attempt to delete work type schemes associated with projects will now receive validation errors and must be updated to follow the migration steps above.
For more information, see:
Work type schemes in the Jira Platform REST API documentation
Community post: Project fields association improvements for additional context
Related: CHANGE-2527 (deprecation notice)
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.
Forge app REST APIs let your app expose its own HTTP endpoints so that external systems can call your app code running on Forge.
These Forge app REST APIs are secured with developer-defined scopes and use 3LO (OAuth 2.0) for authentication and authorization. You define the endpoints in your app manifest using the apiRoute module.
This capability is currently in Preview and is available for Jira and Confluence Forge apps. This is currently not available in Isolated Cloud.
To learn how to expose REST APIs in your Forge app, see Expose Forge app REST APIs. For a step-by-step tutorial on configuring a 3LO integration to access exposed REST APIs, see Access REST APIs exposed by a Forge app.
As announced in July 2025, a number of glyphs for the Icon component will now be removed.
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.
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
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.
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.
The sidebar will now span the full height of your Atlassian app, making it easier to find and interact with. Starting late November 2025, this update will roll out to all customers who haven’t customized the look and feel of their sites. This change won’t affect the width and height of your Forge and Connect apps.
Along with this, we’re introducing a few improvements to sidebar interactions:
Double-click to collapse: When expanded, double-click the button to quickly collapse the sidebar.
Global shortcut: Use Ctrl + [ to expand or collapse the sidebar at any time.
Helpful tooltips: Tooltips will appear to guide you through the interaction.
For sites with customized look and feel, the full-height sidebar can disrupt intentional design choices, such as:
Custom logos and titles
Favicons
Navigation colors
Dark and light mode settings
Because of this, the sites with customized look and feel won’t receive the update just yet.
For the sites without customized look and feel, we’re opening up the opportunity on Nov 21, 2025 to let you use this feature early and test it with your apps. If you’re interested, please sign up here with your site details.
Rate this page: