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.
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.
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.
What's changing
You can now control access for the jira:uiModifications module for different user types:
Anonymous – users who are not logged in
Unlicensed – users invited to a Jira space without a license (guests in case of Jira)
Customer – JSM portal customers
By default, Forge apps only run for licensed Jira and Jira Service Management users. With this update, you can allow your UI Modifications app to run for anonymous, unlicensed, or customer users by declaring it in your app manifest.
As previously announced, from Jun 29, 2026, UI Modifications will not run for anonymous, unlicensed or customer account users unless the module explicitly declares support for these user types in the Forge app manifest.
What you need to do
To allow your app to work for anonymous, unlicensed, or customer users, add the unlicensedAccess property to the jira:uiModifications module in your manifest.yml file.
1
2
3
4
5
6
7
8
9
10
11
modules:
jira:uiModifications:
- key: ui-modifications-app
title: UI modifications
resource: uiModifications
resolver:
function: resolver
unlicensedAccess:
- anonymous
- unlicensed
- customerOnly include the user types your app needs. For example, if your app only needs to work for anonymous users:
1
2
unlicensedAccess:
- anonymousFor detailed steps, refer to the https://developer.atlassian.com/platform/forge/access-to-forge-apps-for-unlicensed-users/.
The Status Search API now exposes a new optional includeGlobalStatuses query parameter. When set to true on a project-scoped query, the response includes global statuses (statuses not tied to any specific project) alongside the project's own statuses. Defaults to false. This parameter is only relevant for project-scoped queries.
This supports ongoing work to allow team-managed workflows to use global statuses, giving admins more flexibility and consistency across projects.
Following the deprecation announcement last year, access to the old workflow editor will be removed for all customers starting July 13, 2026.
What you need to do
Review your apps: If you own workflow-related apps, ensure your rules provide a high quality experience in the new editor.
Implement rule descriptions: We recommend providing dynamic configuration descriptions for Forge and Connect workflow rules. This helps admins understand your app's rules at a glance within the new editor.
Test and report issues: If you encounter any behavior issues in the new workflow editor, please raise a support ticket.
For more details refer to the community announcement.
The Workflow Search API now supports a new optional projectId query parameter. When provided, the search returns only the workflows used by that project. You can combine it with the existing scope parameter, but the project must belong to the same scope you specify - otherwise no workflows are returned.
We've introduced a structured process for partners and Atlassian to jointly investigate security incidents affecting your app or the customer data it handles.
What's changing
Log sharing for Forge apps: Atlassian can now share incident-scoped platform logs and app telemetry with you during an investigation. This provides the data you need to diagnose and resolve issues faster.
A single reporting path: You can now report security incidents through the new developer support portal form. This form serves as the shared record for both you and Atlassian.
What you need to do
Review the program overview page to understand eligibility and support levels.
Ensure your security contact information is up to date in the partner account to ensure you are ready before an incident occurs.
Resource-restricted tokens are now available for all developers creating new 3LO apps.
When creating a new OAuth 2.0 (3LO) app via the Developer Console, you can now opt in to resource-restricted tokens. This ensures that access tokens issued for your app are scoped to only the specific Atlassian site a user explicitly selects during consent rather than granting broad access across all sites.
The onboarding guide for Resource restricted apps is available here:
https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/#oauth-2.0-(3lo)-apps
We’re enhancing the jira:uiModifications module to support interactions with different user types in Jira.
Apps with UI Modifications that need to work for anonymous users must explicitly declare this in the app manifest using the unlicensedAccess attribute.
This change will take effect on Jun 29, 2026. We recommend that you deploy an update to your app before this date to avoid any interruption to your app’s functionality for anonymous users.
Add the anonymous value to the unlicensedAccess attribute for each jira:uiModificationsmodule that needs to execute for anonymous users in Jira.
1
2
3
4
5
6
jira:uiModifications:
- key: your-app-key
title: Your UI Modification
resource: yourResource
unlicensedAccess:
- anonymousFor more information, see the guide on Access to Forge apps for unlicensed users.
From Monday Jun 29, 2026 onwards, UI Modifications modules will not be executed for anonymous users unless the module explicitly declares it.
What’s changing
You can now enable guest access for the following Jira Forge modules:
jira:customField
jira:customFieldType
jira:issuePanel
This update allows your apps to run for unlicensed users (guests) who have been invited to a single Jira space. By default, Forge apps only run for licensed Jira and Jira Service Management users.
What you need to do
To allow your app to serve unlicensed and guest users, add the unlicensedAccess property to the relevant modules in your manifest.yml file.
1
2
3
4
5
6
7
8
9
10
modules:
jira:customField:
- key: my-object-field
name: My object field
type: object
...
unlicensedAccess:
- customer
- anonymous
- unlicensed // <- newFor detailed implementation steps, refer to the guide for unlicensed users.
A new Rovo-powered AI chat widget is now available for all logged-in users on https://developer.atlassian.com. Located in the bottom right corner of developer documentation pages, this assistant can answer questions, surface relevant docs, and help you build on the platform faster.
Key features include:
Contextual answers: The chat understands the context of your question and provides relevant answers rather than generic search results.
Developer-focused knowledge: Trained on Atlassian developer documentation, the assistant understands Forge, REST APIs, Marketplace, and platform concepts.
Natural language understanding: Ask questions in plain language; no need to know exact documentation titles or keywords.
Follow-up questions: Continue a conversation naturally with follow-up questions to drill deeper into a topic.
Source transparency: The widget displays the specific documentation and support sources used to generate each answer.
Conversation history: You can access and review your previous interactions for up to 28 days.
Independent operation: The assistant works independently of your product licenses and organization-level AI settings.
For more details on how the assistant handles data and what sources it uses, see the Atlassian developer AI chat documentation.
You can now use Jira entity properties (issue, project, and user) to filter Forge trigger events and include them in the delivered event payload. This allows your app to process only relevant changes and reduces unnecessary executions.
What’s changing
Entity property filtering: You can now define expressions in your manifest.yml that use Jira entity properties to filter events before they trigger your app.
Payload enrichment: Relevant entity properties can now be included directly in the event payload, eliminating the need for additional REST API calls to fetch this data.
What you need to do
Update your manifest.yml to include expression filters using entity properties.
Update your event handlers to utilize the enriched payload data.
For more information, see the Forge Trigger module reference.
Forge custom fields and Forge custom field types are now displayed as columns in Jira's https://support.atlassian.com/jira-software-cloud/docs/what-is-the-list-view/ (New Issue Navigator).
What's new:
Forge custom fields appear as selectable columns in the List View.
When a formatter is defined in your manifest, the List View evaluates and displays the formatted value instead of the raw stored value.
Limitations:
Read-only — Inline editing of Forge custom field values is not available in the List View. Users must open the issue to edit.
No Custom UI / UI Kit rendering — The view.resource component is not rendered; field values are displayed as text only.
Read more here :
Forge apps using the UI Modifications API configured for Issue View will now have their modifications applied when issues are opened via ViewIssueModal (for example, from global pages, admin pages, or custom UI panels).
Previously, UI Modifications were not loaded silently in this context. This applies to all supported project types, and requires no changes to your app's manifest or code
For more details, see the Jira UI modifications documentation.
Rate this page: