This page includes changelog entries and updates related to adopting Forge from Connect. Use this page to keep track of what Connect equivalent functionality is being shipped in Forge, and what resources are being added to help you move from Connect to Forge.
For updates about changes to the Forge platform, see the Forge changelog in the Forge documentation.
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.
KB Article search & view endpoints are now supported for Forge apps for customer account users / unlicensed users
We have added Forge OAuthScope support for the endpoint /rest/servicedeskapi/knowledgebase/article/view/{pageId}. If your manifest has
1
2
3
4
permissions:
scopes:
- read:servicedesk-request
- read:knowledgebase:jira-service-managementthen Forge apps should fetch contents of the article(page) for portal customers.
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.
The messaging covers:
Connected Apps page: Admins will see a message on installed apps utilising Connect components indicating the platform is approaching end of support and prompting them to check their app. This messaging will change to be app-specific once you have adopted the connectToForgeMigration module and declared your intent to migrate.
What you need to do:
Review the messaging on your canary tenants to understand what your customers will see.
Adopt the connectToForgeMigration module in your Forge manifest to provide app-specific migration guidance directly within the customer-facing notices.
If you are not yet enrolled in DCP and would like to preview, see the https://developer.atlassian.com/cloud/jira/platform/developer-canary-program/.
A changelog notice will be issued at least one week prior to this change going live to production instances
Rollout of this messaging will be staged across 3 months, starting with apps who have not declared any intent to migrate.
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 :
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.
If your app has yet to migrate fully to Forge (or has a migration plan), you can adopt the new connectToForgeMigration module in your Forge manifest (docs here). This module lets you provide a URL to your migration guidance, which will be surfaced directly in the messaging customers see, replacing the generic notice with app-specific information.
What you need to do:
If your app is in the Developer Canary Program, expect to see customer messaging on your canary tenants starting Jun 2, 2026.
Adopt the connectToForgeMigration module in your manifest to customise the guidance your customers will eventually see.
Production rollout for public apps is planned to start in July. You will receive at least one week's advance notice before that happens. There will be an extended rollout of this messaging across 3 months. From September onwards, all customers with apps installed that use any Connect modules will see this messaging.
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
You can now migrate a Connect Jira Issue Field module to Forge's Custom Field module. The functionality is now available for Text (text) and Rich Text (rich_text) fields.
See https://developer.atlassian.com/platform/adopting-forge-from-connect/migrate-jira-issue-fields/#text-and-rich-text-fields for more details.
Following Forge modules - jira:customField, jira:customFieldType and jira:issuePanel can now run for unlicensed and anonymous users in Jira and Jira Service Management. This means your apps will work on publicly accessible pages and for users who don't have a full Jira and JSM license.
By default, Forge apps only run for licensed Jira and JSM users. To allow your app to serve unlicensed and anonymous users, add the unlicensedAccess property to your modules in manifest.yml.
Please refer to following guide for more details - https://developer.atlassian.com/platform/forge/access-to-forge-apps-for-unlicensed-users/#introduction.
App developers can now use the connectToForgeMigration manifest module to share their Connect to Forge migration plans and commitment status with Atlassian and their users. This experience is currently limited to developer canary tenants with private apps.
Apps with public Marketplace listings will remain unaffected. However, we encourage you to add this module to your production app, so you can receive the updated behaviour as soon as it goes live.
Please see documentation here.
This module should be added to every major version of your app. It is available for apps extending Jira and Confluence.
Edit May 27, 2026: Clarified the "Apps that have not yet completed the transition" section. This policy only applies to apps that were affected by CHANGE-3109 (Forge apps with over 50,000 users that were temporarily moved to major-version-only updates).
Going forward, the blanket classification of all updates as major version updates is being replaced with a per-app policy based on each app's migration status.
Apps that have completed the Connect-to-Forge transition: Any app whose latest deployed version contains only Forge modules and scopes -with no remaining Atlassian Connect modules - will be re-enrolled into minor version updates once that version has been released. The proportion of the install base that has upgraded to the latest version is not a factor; what matters is that a bulk-upgrade path existed from the last version that included Connect modules to the current Forge-only version.
54 apps that already meet this criteria have been moved back to minor version updates, and we will be refreshing that list on a weekly cadence.
Apps that have not yet completed the transition: Apps affected by CHANGE-3109 that still include Connect modules in their latest deployed version will will not be able to use minor version updates indefinitely. This measure protects platform stability by ensuring that API traffic from these very large apps continues to be managed through controlled rollouts rather than automatic minor-version upgrades.
Backporting changes to older major versions (temporarily restricted)
For now, you can’t publish updates to earlier major versions. This temporary restriction is in place for the same reason large apps were moved to controlled rollouts: to prevent large, high-impact changes from being automatically applied to a significant number of customers and to protect platform stability.
If you need to backport a fix to an older major version, we may be able to make an exception on a case-by-case basis. Please reach out to Atlassian with the app details, the version you need to backport to, and the rationale for the change.
As always, this policy has no effect on how apps qualify for the Forge revenue share rate. Your latest deployed app version determines revenue share eligibility.
For detailed information on how to use forge version bulk-upgrade, see https://developer.atlassian.com/platform/forge/cli-reference/version-bulk-upgrade/.
Please see the previous change here: https://developer.atlassian.com/changelog/#CHANGE-3141
A back-end change required to safely re-enable minor version updates is in the process of being rolled out. As a result, all updates to Forge apps with over 50,000 users continue to be classified as major version updates.
Please continue to use the forge version bulk-upgrade command to roll out updates to customer sites until further notice. We expect to have this change out the door soon. Please do not rely on minor version updates until the next changelog announcement confirms that it is safe to do so.
Atlassian will discontinue support for the Atlassian Connect Express (@atlassian/atlassian-connect-express) and Atlassian Connect Spring Boot (atlassian-connect-spring-boot) frameworks alongside the end of support for the Atlassian Connect platform.
As of April 30, 2026, Atlassian has ceased development of new features for these frameworks. While we will continue to patch vulnerabilities and assess bug fixes on a case-by-case basis for the time being, this support will end completely when the Connect platform enters its final EOS phase in Q4 2026. When that happens, Atlassian will no longer:
Investigate or remediate breaking changes caused by product or platform updates.
Provide official maintenance or security patches for these frameworks
Both frameworks will remain available as open-source projects under the Apache 2.0 license, and their source code will continue to be accessible at:
Atlassian Connect Express: https://bitbucket.org/atlassian/atlassian-connect-express
Atlassian Connect Spring Boot: https://bitbucket.org/atlassian/atlassian-connect-spring-boot
Developers who wish to continue using these frameworks can fork and maintain them independently. However, any future maintenance (including addressing breaking changes or security issues that arise after Connect enters EOS) will be the responsibility of the community or individual developers.
For details on the Atlassian Connect EOS timeline and phases, see:
https://www.atlassian.com/blog/developer/announcing-connect-end-of-support-timeline-and-next-steps
You can now migrate a Connect Jira Issue Field module to Forge's custom field module. The functionality is now available for Single select and Multi select fields.
See https://developer.atlassian.com/platform/adopting-forge-from-connect/migrate-jira-issue-fields/ for more details.
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.
Rate this page: