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
We've updated the minimum compatible Node.js version for the Forge CLI. The CLI now requires Node.js 22.23.4, 24.22.1, 26.12.1, or newer.

Node.js 20 has reached end of life and is no longer supported. To continue using the Forge CLI to develop and deploy your apps, you must upgrade your local development environment to one of the supported versions listed above.

What you need to do

1. Check your current Node.js version by running node -v in your terminal.

2. If you are running a version older than the requirements, download and install a supported version from the Node.js website.

3. Update your Forge CLI to the latest version by running:npm install -g @forge/cli@latest

4. Verify the installation by running forge --version.

For more information on setting up your development environment, see the Getting started guide.

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.

What's changing
We've introduced new experimental REST APIs for managing space policies in Jira Cloud. Space policies allow site administrators to govern the creation and usage of fields and statuses in team-managed spaces, helping to prevent configuration sprawl and maintain instance health.

The following experimental endpoints are now available:

Viewing policies

• GET /rest/api/3/policies — Get all policies

• GET /rest/api/3/policies/project/{projectIdOrKey} — Get project policy state

• GET /rest/api/3/policies/project/{projectIdOrKey}/rules — Get project policy rules

Applying policies to projects

• POST /rest/api/3/policies/{policyId}/apply — Apply a policy to projects

• POST /rest/api/3/policies/{policyId}/remove — Remove a policy from projects

• PUT /rest/api/3/policies/project/{projectIdOrKey}/policies — Set the policies applied to a project

• POST /rest/api/3/policies/project/{projectIdOrKey}/validate — Validate policy application to a project

What you need to do

1. Review the Jira Cloud space policy API documentation to understand the available methods and data structures.

2. Note that these APIs are currently experimental and may change without notice.

3. If you are building integrations that create fields or statuses, ensure you handle potential blocks when a space policy is active.

Dynamic modules, customer-managed egress, and customer-managed remotes are now generally available on the Forge platform.

• Dynamic modules let a Forge app register and manage modules at runtime through the Dynamic Modules API, rather than declaring them statically in the manifest. These modules are available across Jira, Confluence, and Jira Service Management.

• Customer-managed egress lets Atlassian administrators configure the external domains a Forge app may send data to.

• Customer-managed remotes let Atlassian administrators configure the remote backends a Forge app may communicate with.

For more information, see Dynamic modules and Customer-managed egress and remotes.

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:

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 are reintroducing direct JQL query validation to the Search REST API (/rest/api/3/search/jql) specifically for queries that use custom JQL functions.

Previously, when the new Search REST API was introduced, JQL validation was moved exclusively to the parse endpoint (/rest/api/3/jql/parse). Based on developer feedback, we are bringing this capability back to the search endpoint for custom JQL functions.

If a JQL query containing custom JQL functions is invalid, malformed, or references unsupported functions or arguments, the search API will now return an immediate HTTP 400 Bad Request with detailed error messages. This change applies exclusively to custom JQL functions; native JQL queries and other general usages of the search endpoint remain unaffected and will continue to follow existing validation behaviors.

What you need to do

1. Simplify your integration: If your app uses custom JQL functions, you no longer need to make a separate pre-flight call to the JQL parse API (/rest/api/3/jql/parse) to validate these queries before searching.

2. Update error handling: Ensure your search API integrations are prepared to handle HTTP 400 Bad Request responses and can inspect the returned error messages when executing queries that include custom JQL functions.

3. Review documentation: For more information on constructing queries, refer to the Jira Search REST API documentation.

JQL searches that use user entity properties with the voter, watcher, or creator fields are being deprecated. If you maintain apps or custom integrations that rely on these searches, you must update your queries before support is removed to ensure your data remains searchable.

What's changing
Jira is deprecating support for user entity property searches on the voter, watcher, and creator fields.

• Impact: After the removal date, any JQL queries or API requests attempting these searches will be rejected with an UnsupportedOperationException.

• Note: User entity property searches for other fields, such as assignee and reporter, remain fully supported.

• Deprecation date: November 16, 2026

What you need to do

Review your apps and integrations for user entity property searches on the deprecated fields and migrate them. Use custom fields when the data must be searchable through core JQL, issue entity properties when the data is issue-scoped, or app-managed storage when the data is application-specific and does not require native JQL support.

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.

Jira is updating how text-field queries using the =, IN, or NOT IN operators are handled. Previously, these operators required an exact match of the full field value. For example, textField = "urgent" would only match if the field contained exactly "urgent" and nothing else.

With this update, these operators now perform an exact phrase search. This means the query will match if the specified phrase appears anywhere within the text field, even as part of a longer string. This behavior is now consistent with using the ~ operator with escaped quotes (for example, textField ~ "\"urgent\"").

Key details of the new behavior:

• Broader matching: textField = "urgent" now matches "urgent", "urgent issue", and "very urgent issue". Previously, it would have only matched "urgent".

• Phrase integrity: For multi-word queries like textField = "alpha beta", Jira matches the exact phrase in that specific order. It will match "prefix alpha beta suffix" but will not match "beta alpha" or "alpha something beta".

• Case-insensitivity: Matching remains case-insensitive (e.g., "Alpha Beta" matches "alpha beta").

• Stemming: Text search still applies stemming, so a search for "run" may also match "running" or "ran".

• List operators: textField IN ("alpha beta", "urgent") now matches values containing either exact phrase anywhere in the text.

What you need to do
If you use saved filters, dashboard gadgets, or automation rules that rely on = or IN for text fields, you should:

1. Review your JQL queries to ensure they still return the expected results. Because the matching is now broader (matching phrases within longer text rather than the full field value), you may see more results than before.

2. If you require a search that matches words in any order, switch to the ~ operator without escaped quotes (for example, textField ~ "alpha beta").

3. Update any internal documentation or training materials to reflect that = now functions as a phrase search for text fields.

Global Statuses in team-managed projects (TMP) will become Generally Available (GA) from October 12th, 2026. This follows on from the earlier opt-in Beta where users could try this out via Jira Labs. This rollout enables better status consistency for our customers across team-managed spaces.

Key Updates:

• The feature is now active by default and will no longer requires an opt-in via Jira Labs.

• Team-managed spaces now support shared, site-wide global statuses in workflows and boards.

• No structural API changes have been introduced; all existing workflow endpoints and payloads maintain full backwards compatibility. No action is required for existing integrations.

A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-150-jira-expression-enhancements-for-rich-text-fields/103048 .

We’re launching an addition to our new dashboards Forge module, dashboard:filters, that allows Forge widgets to integrate natively with Atlassian dashboard filters. This early access program (EAP) enables you to test the module and provide feedback before general availability.

What’s changing
The dashboard:filters module allows your Forge apps to:

• Create custom filters: Build your own set of dashboard filters with custom UI to provide tailored filtering experiences for users.

What you need to do

1. Sign up for the EAP: To participate and access the full documentation, please sign up for the EAP here.

2. Review the documentation: Once enrolled, refer to the module documentation for manifest syntax and implementation details.

3. Provide feedback: Use the feedback channels provided in the EAP welcome materials to share your findings and feature requests.

By signing up for this EAP, you acknowledge that use of the dashboard filters integration is governed by the Atlassian Developer Terms. This feature is considered Early Access Materials as set forth in Section 12 of the terms, and is subject to applicable conditions and disclaimers.

You can now use display conditions to hide sub-pages or sections in several Jira Forge modules. This allows you to show or hide UI elements based on specific criteria, such as user permissions or project types.

The following modules now support display conditions on their pages and sections child properties:

• jira:adminPage

• jira:globalPage

• jira:projectPage

• jira:projectSettingsPage

• jira:personalSettingsPage

🛠️ 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.