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.

The visual refresh of the labelling system (which consists of our tag, lozenge, and badge components) is now available by default, both when using the components directly and in Forge UI Kit. The feature flag that previously controlled access to the refreshed look has been removed, so you no longer need to enable it to use the new appearance.

This follows our earlier announcement of the labelling system changes, when the refreshed look was available behind a feature flag.

Date label and Date dropdown trigger are also now generally available (GA). These new additions to the labelling system were introduced without a feature flag.

Static macros for Confluence on Forge have progressed from EAP and are now available in Preview.

Static macros allow you to render Forge macro content natively on Confluence pages without iframe overhead. By returning ADF or Confluence Storage Format nodes directly, your app improves page load performance and provides a more seamless user experience.

Key features of the Preview release include:

• Native rendering: Content is rendered as part of the page HTML, eliminating iframe latency.

• Batch rendering: The concurrency property allows you to process multiple macro instances in a single invocation, further reducing app overhead.

• Export support: Static macro content is automatically included when exporting pages to PDF or Word.

The feature is suitable for early adopters in development, staging, and production environments.

What you need to do

1. Update your manifest: Add the static property to your macro module in manifest.yml.

2. Implement the render function: Ensure your function or endpoint is configured to receive an array of macro arguments and return the appropriate ADF or Storage Format nodes.

3. Review the documentation: For full configuration options, schemas, and best practices, see the static macros documentation.

A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-149-forge-user-impersonation-fui-addressing-connect-parity-gaps-edge-cases/102987

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.

What’s changing?

In preparation for the upcoming Developer Preview release of Forge Static Macros, access to the early access program (EAP) for this capability is now closed.

We want to thank everyone who participated in the EAP and provided valuable feedback. Your insights have been instrumental in shaping the next phase of Forge Static Macros.

What you need to do

If you are currently participating in the EAP, you can continue to use the feature.

If you missed the EAP, stay tuned to this changelog for the Developer Preview release announcement to start building with Forge Static Macros.

Upgrading a Connect app installation to a Forge-only version previously called the Connect uninstalled lifecycle hook before the Forge installation event fired. This was indistinguishable from a customer uninstalling the app.

The uninstalled hook is now suppressed for both migration paths:

• an already-harmonised (Connect on Forge) app installation upgrading to a Forge-only version

• a Connect app installation upgrading directly to a Forge-only version under the same app key

What's changing
Apps adopting Forge from Connect can now use the migratedFrom property in a Forge macro module to map one or more existing Connect macro keys to a single target Forge macro. This allows you to consolidate multiple legacy macros into a new Forge implementation.

Key details of this feature:

• Resolution: Existing Confluence content that uses any of the listed Connect macro keys will automatically resolve to the target Forge macro.

• Scope: The listed keys must belong to the Connect app declared in the app.connect.key field of your manifest.

• Responsibility: The target Forge macro is responsible for handling the configuration and parameters stored by the previous Connect macros. Note that migratedFrom does not transform parameter schemas.

• Exclusivity: A legacy macro key can be claimed by only one Forge macro on a given tenant.

• Current limitation: Forge-to-Forge macro consolidation is not currently supported; this property only supports mapping Connect macro keys to Forge macros.

What you need to do
To consolidate your Connect macros, update your manifest.yml file to include the migratedFrom property under the target macro module:

For more information on migrating macros and handling legacy data, refer to the Adopting Forge from Connect: Migrate macros documentation.

As per our previous announcement, we will be progressing admin-facing migration messaging for apps that have declared a migration intent of ‘yes’ on the Connected Apps page from the Developer Canary Program to production instances. This rollout will begin in approximately two weeks.

• Apps that have declared connectToForgeMigration with a migration intent of "yes"

The following app categories have already been rolled out to receive admin-facing messaging as per our previous changelog:

• 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)

1. 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/).

2. Declare your migration intent as this determines which cohort your app falls into and when messaging appears.

3. Provide a migration URL. This URL will be surfaced directly in customer-facing notices, replacing the default Atlassian messaging with your app-specific guidance.

4. Preview the experience now using the Developer Canary Program. Customer messaging is already live on canary tenants for apps that have declared ‘yes’ to the migration intent. 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.

We’ve released the new adoption-status CLI command that analyses your manifest.yml and shows:

• How much of your app has been migrated to Forge

• Which migration requirements are complete

• What remains to be done before you can finish your migration

From your Forge app directory, run:

No installation is required.

If your manifest is in a different location, specify its path with the --manifest option:

For detailed information about the command and its output, see https://developer.atlassian.com/platform/adopting-forge-from-connect/adoption-status-tool/.

We are extending the Connect End of Support (EOS) date from December 2026 to January 31, 2027. This extension is intended to give partners and developers additional runway to complete their migrations without overlapping with end-of-year activities and annual planning cycles.

For more information, please read https://www.atlassian.com/blog/development/getting-ready-for-connect-end-of-support

Over the coming weeks, if your Marketplace app is still running on Atlassian Connect, you can expect to receive a direct ECOHELP ticket from us.

Why we're doing this: Jan 31, 2027 marks end-of-support for Connect. We want to make sure every vendor has had a direct, personal heads-up with enough runway to complete their migration.

Who will receive a ticket:

• Group 1 — Connect apps (no Forge manifest at all)
• Group 2 — Forge apps with remaining Connect modules

What we'll ask:

1. Leave a comment and fill in the short survey at the top of the ticket

2. Complete your migration before Jan 31, 2027
   The description also covers what to do if you're already migrated, in progress, or planning to discontinue — plus links to the migration guide and developer community.

The devops:securityInfoProvider module has moved from preview to general availability. Your Forge app can now send security information (such as vulnerabilities and security containers) to Jira and surface it in the development panel of Jira Software issues.

Known limitation: Currently, Forge apps using the devops:securityInfoProvider module require a Connect key. This means apps using this module cannot be listed as new apps on the Atlassian Marketplace - only existing Connect-based security provider apps migrating to Forge are unaffected by this restriction.

We're actively tracking this limitation in https://jira.atlassian.com/browse/ECO-1602 and will update this page when it's resolved.

Get started

See the https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-software-security-info/ for the full manifest schema and property details.

For a step-by-step guide, check out the https://developer.atlassian.com/platform/forge/security/.

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.