Changelog

Starting February 1, 2027, we'll progressively roll out a change to the portfolioChildIssuesOf() JQL function so its results include work items in team-managed spaces. Today, the function only follows hierarchy in company-managed spaces, so searches can miss descendants that live in team-managed spaces.

• portfolioChildIssuesOf() will return descendants through valid team-managed space hierarchies, including supported relationships between company-managed and team-managed spaces, such as a team-managed epic under a company-managed initiative.

• Queries that use NOT IN portfolioChildIssuesOf() will exclude these additional work items.

• Results continue to respect hierarchy rules, user permissions and issue security.

• REST API request and response formats don't change.

If your app, saved filters or automation rules assume that team-managed work items are excluded from portfolioChildIssuesOf() results:

1. Find the queries that use portfolioChildIssuesOf().

2. Check whether team-managed work items in the results would affect your logic.

3. If they would, update your queries or result handling before February 1, 2027.

We'll publish another update when the rollout starts.

What's changing
From January 1, 2027, Atlassian cloud will add new IP address ranges as we expand our cloud infrastructure.

The new ranges are in addition to our existing ones.

The new ranges are:

• New range: 131.162.88.0/21

  • Requests to Atlassian (browsers and your clients calling Atlassian APIs): 131.162.88.0/23

  • Requests from Atlassian (webhooks, Connect lifecycle calls, and other requests from Atlassian to your app): 131.162.90.0/23

What you need to do
If your app, remote backend, or integration allowlists Atlassian IP addresses, you must add these ranges before January 1, 2027, to avoid service interruptions.

These ranges are already included in our official IP range list (viewer tool). If you automate your allowlist updates from this file, no further action is required. For more details, see our documentation on IP addresses and domains for Atlassian cloud apps.

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:

1. Update your app manifest to use the new dashboards:widget and dashboards:backgroundScript modules.

2. 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:

1. Review the dashboards:widget manifest reference for configuration details and schema.

2. 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.

3. 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.

The Bulk fetch issues API (POST /rest/api/3/issue/bulkfetch) now supports a maximum of 1000 issues in a single request, up from the previous limit of 100. This higher limit is available for requests optimized for efficient processing. https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/1-000-Issues-One-Call-Bulk-Fetch-Gets-a-10-Boost/ba-p/3281867

What's changing
To qualify for the 1000-issue limit, your request must meet the following criteria:

• Explicit field selection: You must explicitly name at least one field to include. Wildcards like *all or *navigable, and requests containing only exclusions (e.g., -description), are not eligible.

• Field count: No more than 100 fields can be explicitly included.

• Single-value fields only: Included fields must not return multiple values (e.g., comment, worklog, or attachment are excluded).

• Restricted expands: The expand parameter must not include changelog, editmeta, operations, renderedFields, transitions, or versionedRepresentations.

What you need to do
No action is required if you wish to continue using the existing 100-issue limit. To take advantage of the 1000-issue capacity:

• Update your request payload to explicitly list the specific fields you need.

• Remove any multi-value fields or restricted expand parameters.

• Increase your batch size up to 1000 issueIdsOrKeys.

If you require multi-valued data or changelogs for a large set of issues, we recommend splitting the work: use one 1000-issue call for "cheap" fields and separate, narrower calls for complex data. For changelogs, use the Bulk fetch changelogs endpoint to avoid the 40-item cap imposed by expand=changelog.

For more details, see the Bulk fetch issues reference documentation.

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.

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.

Only include the user types your app needs. For example, if your app only needs to work for anonymous users:

For detailed steps, refer to the https://developer.atlassian.com/platform/forge/access-to-forge-apps-for-unlicensed-users/.

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.

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.

For 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.

For detailed implementation steps, refer to the guide for unlicensed users.