We've published a new guide - https://developer.atlassian.com//platform/forge/working-around-jql-1000-limit/ - to help Forge app developers handle the custom JQL functions returning more than 1,000 values. The guide covers four practical strategies and code examples, along with trade-off comparisons, and guidance on when to use which approach.

Following our deprecation notice on Sep 29, 2025:

• Customers can no longer install Connect private apps.

• Partners and developers can no longer update existing Jira or Confluence apps using a Connect descriptor on the Atlassian Marketplace.

From now on, private apps can only be installed via Forge installation links. See https://developer.atlassian.com/platform/forge/distribute-your-apps/ for instructions on sharing these links to your customers.

This milestone is in line with our timeline for ending support for the Connect platform.

Forge apps with app.connect.key declared in their manifest can now retrieve the Connect clientKey for an installation via a reserved, read-only app property. See Retrieving the Connect clientKey in Forge for instructions.

We've improved how errors from https://developer.atlassian.com/platform/forge/manifest-reference/modules/jql-function/ are surfaced to end users in Jira. This functionality will be rolled out for all customers in next 2 weeks.

Previously, when a custom JQL function returned an error, Jira treated it as a generic server error and End users would see a non-descriptive message — "We couldn't load your search results".

Now, errors returned by custom JQL functions are classified as JQL validation errors and displayed inline, just like native JQL errors. If your app returns a custom error message, that message is shown directly to the end user.

The jira:globalBackgroundScript module is now more powerful and adds following major functionality to the module -

• Experience-based access control - Restrict which Jira views your script runs on using the experience property in the manifest. If no experience is specified, the script will not run anywhere.

• Modal support - Open modal dialogs from a background script on any allowed view using the https://developer.atlassian.com/platform/forge/apis-reference/ui-api-bridge/modal/.

• View context access - Access view-specific context such as issueKey, projectId, boardId, and project.type depending on the current Jira view.

Please read more here https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-global-background-script/.

We are pleased to announce the availability of multi-user app ownership for OAuth 2.0 (3LO) apps in the developer console.

• Multiple admins - You can assign multiple admins to your OAuth 2.0 apps in the developer console.

• Ownership transfer - The OAuth 2.0 app ownership transfer option is now available in the developer console.

We've introduced a new asynchronous bulk API that allows Jira administrators to pin or unpin Forge app issue panels to multiple projects in a single request — processing up to 1,000 projects at once.

For app developers: Integrate this API into your Forge app to give Jira admins a centralized view for managing issue panel visibility across projects. For full API details, see: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-panels/#api-rest-api-3-forge-panel-action-bulk-async-post

We’ve introduced a platform-level URL persistence and redirect feature for apps migrating from Connect to Forge. Jira and Confluence will now accept legacy Connect URLs (including full path, query parameters, and fragments) and transparently redirect them to the corresponding Forge app module. For more information on how it works, please see the documentation here.

We have now added the ability to use the following as dynamic modules, available under Forge’s Early Access Program (EAP):

• Issue Action

• Issue Activity

• Issue Panel

• Issue Context

• Custom Field

• Custom Field Type

• JQL Function

• Entity Property

To start testing, sign up for the EAP here.

We’re introducing support for multiple field contexts per project in Jira Cloud. This allows more than one context to exist for a single project across different issue types, and multiple default values to be set for different issue types within a single context.

As part of this change, the existing REST APIs for managing context default values are being deprecated and will be replaced by new APIs that support multiple default values.

Deprecated APIs:

• Get custom field contexts default values

• Set custom field contexts default values

Deprecation Timeline:

• July 2026: New default values REST APIs introduced. Existing "Get" API will return an error for contexts with multiple defaults; "Set" API will override all issue types in a context.

• October 2026: Existing default values APIs will be removed.

What you need to do:
If you use the affected APIs, plan to migrate to the new REST APIs before October 2026.

You can now nominate genuine migration blockers or major customer‑impact risks via the “Request review” flow on FRGE issues.

This flow will allow us to triage and assess requests to address remaining blockers to Forge migration before Connect end of support in December 2026. We’ll review requests over 3 monthly cycles, then freeze decisions.

Please review for existing tickets before creating new FRGE tickets. You may also review the announcement.

Effective March 2, 2026, we are starting the phased enforcement of points-based quota rate limits for Jira and Confluence Cloud REST APIs. The rollout will begin with a small percentage of apps and gradually expand over several weeks, allowing us to closely monitor progress and minimize any disruption. API requests will start consuming points based on the work they perform, with app-level quotas applied consistently across two tiers:

1. Global Pool (Tier 1)

2. Per-Tenant Pool (Tier 2)

All Forge, Connect, and OAuth 2.0 (3LO) apps are in scope. API token-based traffic is not affected. The vast majority of apps are already operating well within these limits and will not be affected.

• To learn whether points-based quota enforcement has started for your app, inspect your API response headers. Quota-related headers with a Beta- prefix (e.g., Beta-RateLimit-Policy: "global-app-quota") indicate enforcement has not yet begun for your app. When enforcement begins, these transition to their non-prefixed equivalents (e.g., RateLimit-Policy: "global-app-quota").

• Jira REST APIs use multiple rate-limiting systems (quota, burst) that are transitioning to a unified structured headers(Beta-RateLimit, Beta-RateLimit-Policy)independently. The Beta- prefix on a header indicates that the system has not yet transitioned to production for your app. Use the policy name in the header (e.g., "global-app-quota" or "tenant-app-quota" for quota and for burst"jira-burst-based" ) to identify which system a header belongs to. Additional rate limit policy transitions to this unified header will be announced separately.

• We plan to discontinue sending quota rate limit values via the X-RateLimit-* headers in the future. A timeline will be published separately.

For full details on how points are calculated, quota tiers, unified header format and values, and best practices for handling rate limits, please refer to:

• Jira Cloud Platform rate limits

• Confluence Cloud rate limits

Following this deprecation announcement on Feb 17, 2026, the Connect Inspector Service is now decommissoned.

We recommend migrating to Atlassian Forge for a more robust Events model, as Atlassian Connect will reach end of support in December 2026.

Developers who still need similar functionality can use the open‑sourced version of the tool.

We are introducing baseline security requirements for Atlassian Government Cloud (AGC) apps, which will take effect on Mar 31, 2026. If you have any questions regarding these new standards, please contact us here: https://ecosystem.atlassian.net/servicedesk/customer/portal/34/group/109/create/579

We’re also publishing our annual update to the general Cloud App Security Requirements for 2026, which includes new provisions for AI security, data protection, and supply chain security. See More details for highlights on this update.

We’re introducing display condition support to the following Jira Service Management (JSM) Forge portal modules as a preview release:

• Portal footer

• Portal header

• Portal profile panel

• Portal request create property panel

• Portal request detail

• Portal request detail panel

• Portal request view action

• Portal subheader

• Portal user menu action

For these JSM modules, Forge apps can now declare displayConditions in the app manifest and have them evaluated by the host, consistent with how display conditions work for Jira and Confluence Forge modules today.

For further details, see the documentation here.