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

The ability to use Forge Dynamic Modules is now available in Preview. These modules are available across Jira, Confluence and JSM. Please see our documentation here for more information.

Thank you to everyone who engaged in our EAP and provided valuable feedback!

Following on from our previous announcement, customer messaging for Marketplace apps is now enabled on tenants enrolled in the Developer Canary Program. This messaging is scoped only to the Connected Apps admin page and in-app messaging will not be available. Only DCP-enrolled tenants are affected, production instances are unchanged.

This gives enrolled partners and developers early visibility into the admin-facing messaging customers will see before it starts to broadly go live in production later, starting 6th July. Please use this window to test and prepare.

Forge custom fields and Forge custom field types are now displayed as columns in Jira's https://support.atlassian.com/jira-software-cloud/docs/what-is-the-list-view/ (New Issue Navigator).

What's new:

• Forge custom fields appear as selectable columns in the List View.

• When a formatter is defined in your manifest, the List View evaluates and displays the formatted value instead of the raw stored value.

Limitations:

• Read-only — Inline editing of Forge custom field values is not available in the List View. Users must open the issue to edit.

• No Custom UI / UI Kit rendering — The view.resource component is not rendered; field values are displayed as text only.

Read more here :

• https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field/#list-view

• https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field-type/#list-view

As Connect approaches end of support in December 2026, we are starting to roll out customer messaging in the admin experience to inform admins when an installed app runs on a soon to be unsupported platform, Connect. Following on from our previous announcement, this messaging will gradually rollout over the next week to be live in production for non-public apps only and is scoped to the admin experience, end users will not see any notices at this stage.

On Jun 2, 2026, we will enable customer messaging on Developer Canary tenants for public apps. This will include notices in admin facing experiences so enrolled partners can preview the exact messaging their customers will see and have the chance to adopt the new connectToForgeMigration module in their manifest before it goes live in production.

A new RFC is ready for review at RFC-136

The jira:actionValidator module (Preview) now supports the workItemTypeChanged action across multiple flows, enabling custom validation whenever a user changes a work item's type. The validator is triggered in:

• Issue view - the user changes the work item type from the type field on the issue view.

• Move issue - when the work item type changes as part of moving an issue.

• Bulk move/migrate - the work item type changes as part of a bulk move or migration.

• Convert to subtask - when a standard work item is converted to a subtask type.

• Convert subtask to a work item - when a subtask is converted to a standard work item.

Also, a new context variable newIssueTypeData (type: IssueType) has been onboarded alongside the existing newIssueType (type: String, returns the issue type ID), allowing more refined conditions on the target work item type within your Jira expression.

Read more here - https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-action-validator/#workitemtypechanged