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 Service Management 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.
What's changing
Forge display conditions for Jira and Jira Service Management (JSM) modules now support arrays under the and, or, and not logical operators.
Previously, manifest keys had to be unique at each level, which made it difficult to repeat the same condition type or group multiple logical expressions. With this update, you can use an array of condition objects to define complex visibility logic more easily.
For example, you can now structure your manifest to group conditions or repeat the same condition type:
1
2
3
4
5
6
7
8
displayConditions:
or:
- and:
- entityPropertyExists: { entity: user, propertyKey: a }
- entityPropertyExists: { entity: user, propertyKey: b }
- and:
- entityPropertyExists: { entity: user, propertyKey: c }
- entityPropertyExists: { entity: user, propertyKey: d }
What you need to do
No action is required for existing apps, as the previous syntax remains supported. If you want to simplify complex logic or repeat conditions in your Jira or JSM modules, you can update your manifest to use the new array-based syntax.
For more details and examples, see the Forge display conditions documentation.
We’ve fixed an issue where remotes referenced in permissions.external.fetch.client only allowed the default base URL, causing browser requests to regional endpoints to be blocked by the content security policy (FRGE-2205)
You can now read your app’s remote installation region using remoteInstallationRegion in getAppContext(). Adding a client-fetch URL that already exists in fetch.backend now results in a minor version change. See app versioning.
🛠️ Scheduled maintenance window from September 25 @ 5PM PST to Monday, September 28 @ 10AM, AEST
Our support portal is moving to a new home. New ticket submissions and ticket access including comments via email will be unavailable during this window. Starting September 28, submit all requests at Atlassian Support and update your bookmarks. Learn what's changing.
We’re upgrading Jira dashboards to a more modern and flexible experience. As part of this transition, we’re deprecating the legacy Forge modules for dashboards in favor of these new dashboard modules.
What’s changing
The following Forge modules are now deprecated and will be removed on May 17, 2027:
jira:dashboardGadget
jira:dashboardBackgroundScript
These modules are replaced by the new dashboards:widget and dashboards:backgroundScript modules, which are now General Availability (GA). The new modules are designed for the upgraded Jira dashboard surface (also referred to as AVP dashboards).
What you need to do
To ensure your dashboard extensions continue to work on the new Jira dashboard experience, you must migrate your existing modules:
Update your app manifest to use the new dashboards:widget and dashboards:backgroundScript modules.
Complete your migration before the deprecation date of May 17, 2027 to avoid service disruption for your users.
What’s changing
The new Forge dashboard modules are now generally available (GA). These modules allow you to build extensions for the upgraded Jira dashboard experience, which offers a more modern and flexible interface for users:
dashboards:widget: Used to create custom content blocks (widgets) on the new dashboard surface.
dashboards:backgroundScript: Used to run background logic for your dashboard extensions.
The new Jira dashboard experience, which utilizes these modules, is rolling out to customers starting September 23rd, 2026.
What you need to do
You can now start building and deploying apps using these modules for the new Jira dashboard experience:
Review the dashboards:widget manifest reference for configuration details and schema.
If you have existing dashboard extensions using the legacy jira:dashboardGadget or jira:dashboardBackgroundScript modules, you should begin planning your migration to these new modules.
Note that the new dashboard experience coexists with classic Jira dashboards during the rollout period.
What's changing
We are updating how Forge permission checks are implemented in Jira for asApp requests. This internal change simplifies the evaluation process and removes the requirement for permissions to be synced to Jira at installation time.
This update improves the app installation process by reducing the overhead associated with permission synchronization.
What you need to do
No action is required from you. This is an internal implementation change that does not affect how you declare permissions or use asApp in your Forge apps.
The update is being rolled out progressively on a tenant-by-tenant basis.
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.
You can now use UI modifications in the Jira Service Management (JSM) agent view. This is an extension of the existing jira:uiModifications module and covers the views your agents use inside a service project.
What's changing
UI modifications now support three specific agent views:
Global issue create (GIC) - viewType: GICAgentView
Issue view - viewType: IssueViewAgentView
Issue transition - viewType: IssueTransitionAgentView
The agent view supports the same fields and methods as equivalent Jira views but is tailored for service projects.
Key differences include:
Extension context: Exposes the requestTypeId of the work item.
Supported fields: The set of supported fields differs from the JSM request create portal view.
REST API: The UI modifications REST API (GET, POST, and PUT) now accepts these three agent view types. When configuring agent view contexts, portalId must not be set, and requestTypeId is optional (omitting it means the context is not scoped to a specific request type). One of projectId, issueTypeId, or viewType can act as a wildcard, with a maximum of one wildcard per context.
You can use view.getContext() to detect the current view type:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import { view } from '@forge/bridge';
import { uiModificationsApi } from '@forge/jira-bridge';
uiModificationsApi.onInit(async ({ api }) => {
const context = await view.getContext();
switch (context.extension.viewType) {
case 'GICAgentView':
// Runs when an agent creates a work item in a service project.
break;
case 'IssueViewAgentView':
// Runs when an agent opens a work item in a service project.
break;
case 'IssueTransitionAgentView':
// Runs when an agent transitions a work item in a service project.
break;
default:
break;
}
}, () => []);No action is needed if you don't want to support the agent view. If you do want to add agent view support, simply define the context for the Agent View view types using the REST APIs – your Forge app will then be invoked automatically in the agent-specific views.
For more information, see:
What's changing
Forge now supports offline impersonation for Jira Service Management (JSM) portal-only users. This follows our June 12, 2026 release of online impersonation support.
You can now use asUser(accountId) to make asynchronous or background API calls on behalf of portal-only users (also known as customer accounts). For apps using Forge remotes, offline impersonation is supported via the offlineUserAuthToken mutation.
This allows your apps to perform background actions, such as processing data or updating requests, in the context of the portal-only user, while maintaining the appropriate permission checks.
Note that portal-only users can only make asUser() calls to Jira/JSM APIs using corresponding scopes declared in the manifest file.
What you need to do
To use offline impersonation for portal-only users in your app:
Ensure your app has the required scopes declared in the manifest.
Use the asUser(accountId) method in your backend code to call product APIs.
If you are using Forge remotes, implement the offlineUserAuthToken mutation to obtain the necessary credentials.
Redeploy your app to apply these changes.
For more information on how Forge handles access for unlicensed users, see our documentation.
Previous changelog release for online impersonation: https://developer.atlassian.com/platform/forge/changelog/#CHANGE-3278
Reference docs for implementation of offline impersonation in Forge:
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.
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 new customerServiceManagement:crmImport Forge module is generally available from June 30, 2026.
What's changing
This module allows you to add an item under the Manage dropdown on the Customers, Organizations, and Products pages within the customer directory of the Customer Service Management (CSM) app. When a user clicks the item, your app renders content inside a modal dialog.
This extension point is specifically designed for apps that import customer context data from external CRM systems into Customer Service Management, providing a dedicated UI entry point for these integrations.
What you need to do
To start using this module, refer to the customerServiceManagement:crmImport manifest reference for technical configuration and schema details.
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.
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.
On 15 September 2026, the jiraServiceManagement:queuePage Forge extension point will stop loading on Customer Service Management (CSM) spaces in Jira.
What's changing
Apps using this module on CSM queues will stop rendering on that surface from the deprecation date. The module will continue to function as expected on standard Jira Service Management (JSM) spaces.
What you need to do
You should migrate to the dedicated replacement extension point, customerServiceManagement:queuePage, which is generally available from 15 June 2026.
Replace jiraServiceManagement:queuePage with customerServiceManagement:queuePage in your app's manifest.yml.
Review the manifest reference for the new module.
Deploy your changes before the deadline.
Timeline
15 June 2026: customerServiceManagement:queuePage reaches GA.
15 June 2026 – 14 September 2026: Migration window.
15 September 2026: jiraServiceManagement:queuePage stops loading on CSM spaces.
If you cannot migrate in time, please contact Atlassian for case-by-case support.
Migration: replace jiraServiceManagement:queuePage with customerServiceManagement:queuePage in your app's manifest.yml. The new module exposes equivalent functionality on CSM spaces.
Timeline:
15 June 2026 — customerServiceManagement:queuePage reaches GA.
15 June 2026 – 14 September 2026 — migration window.
15 September 2026 — jiraServiceManagement:queuePage stops loading on CSM spaces.
Rate this page: