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.

As per our previous announcement, admin-facing Connect end-of-support (EOS) migration messaging on the Connected Apps page is now rolling out to production instances. This messaging, which was previously limited to Developer Canary tenants, is being deployed in staggered cohorts.

The following app categories will begin receiving admin-facing messaging in production:

• Apps that have declared connectToForgeMigration with a migration intent of NO

• Apps that have declared connectToForgeMigration with a migration intent of UNDECIDED

• Apps that have not adopted the connectToForgeMigration module

• Apps without a Forge manifest (Connect apps)

Apps that have declared connectToForgeMigration with an intent of YES are estimated to begin receiving admin messaging in mid-August. We will provide another changelog entry at least 2 weeks before that change proceeds.

What you need to do

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/) if you have not already.

2. Declare your migration intent - 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.

For details about the full customer-facing experience, see What admins see on the Connected Apps page.

Exemptions

Apps that are blocked by an accepted Connect EOS FRGE ticket will be exempt from customer messaging until one month past the delivery date of the blocking feature. This exemption list is determined exclusively by partners who have submitted a Connect EOS Submission request on these accepted tickets, providing a valid use case and explanation and applies to only the apps that have been marked as affected by the feature in the submission. If an app utilises an affected feature but has not submitted a Connect EOS submission, it will not be exempted from this messaging.

As per our previous announcement, we will be progressing admin-facing migration messaging on the Connected Apps page from the Developer Canary Program to production instances. This rollout will begin in approximately two weeks.

The following app categories will receive admin-facing messaging:

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

Apps that have declared connectToForgeMigration with an intent of "yes" are estimated to begin receiving admin messaging in mid-August. We will provide another changelog entry at least 2 weeks before that change proceeds.

End-user messaging will not be included in this initial rollout. When ready, we'll follow the same approach:

• Release to Developer Canary tenants first for early testing

• Roll out in staggered cohorts

• Provide at least 2 weeks advance notice via the Forge changelog before each rollout stage goes live

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

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

We've added a new Forge module (devops:securityInfoProvider) that lets your app send security information (such as vulnerabilities and security containers) to Jira and associate it with issues. This is now available in preview.

What's new

The devops:securityInfoProvider module surfaces your app's security data directly in the development panel of Jira issues. Apps can write and delete security information using the https://developer.atlassian.com/cloud/jira/software/rest/ via the requestJira function.

To register a provider, declare the module in your manifest.yml and configure the required endpoint handlers:

• fetchWorkspaces: returns the list of workspaces available to the user

• fetchContainers: returns security containers within a workspace

• searchContainers: searches containers matching a query

Two optional lifecycle hooks are also available: onEntityAssociated and onEntityDisassociated, invoked when a container is linked or unlinked from a Jira entity.

Important behaviour to note

When a user uninstalls your app, all security data your app sent to Jira is deleted after a grace period.

There is currently a limitation, where your Forge app must define a Connect app key in order to be able to link workspaces. See https://jira.atlassian.com/browse/ECO-1602

Get started

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

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.

You can now configure product event triggers and scheduled triggers to skip invocations for installations where your app is not actively licensed.

What's changing

By adding the appIsLicensed filter to your trigger modules in manifest.yml, the Forge platform will block trigger invocations for installations where the app's license is already inactive. This helps reduce unnecessary compute usage for unlicensed installations.

This change is specifically designed to address apps with existing inactive licenses (e.g., legacy entitlements that have lapsed). It is separate from the broader platform app suspension behaviour being explored in https://community.developer.atlassian.com/t/rfc-137-forge-app-suspension-behaviour/101092, which covers future suspension lifecycle handling.

This is an opt-in feature. Existing triggers are unaffected unless you explicitly add the filter to your manifest.

What you need to do

To enable this filtering, update your manifest.yml by adding the appIsLicensed: true filter to your trigger modules:

• Open your manifest.yml file

• Locate your trigger or scheduledTrigger modules

• Add the filter property with appIsLicensed: true

For more information, see the https://developer.atlassian.com/platform/forge/manifest-reference/modules/trigger/#filter-reference and https://developer.atlassian.com/platform/forge/manifest-reference/modules/scheduled-trigger/#filter-reference.

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.

Forge apps can now make API calls on behalf of JSM portal-only users. JSM portal-only users (also called customer account users) are customers who access your service desk through the JSM portal but don't have a full Atlassian account.

With this release, asUser() in Forge now works for customer accounts from both the frontend and the backend.

Apps can now perform actions like creating customer requests, reading comments, and updating tickets in the context of the portal-only user, with full permission checks preserved, exactly as they would be for a standard Atlassian account user.

The changes will be reflected upon redeployment of the Forge app.

This change only affects online user impersonation, for offline user impersonation we have a feature request being evaluated here: https://jira.atlassian.com/browse/ECO-1585