Changelog

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.

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.

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.

We've introduced two new components to UI Kit, now available in Preview: AtlassianTile and AtlassianIcon. Use these components to display Atlassian object type icons—such as stories, tasks, epics, blogs, and more—with consistent styling that aligns with the Atlassian Design System.

Both components provide fixed color, size, and styling options for Atlassian object types. Any updates to icon or tile styling in the Atlassian Design System are automatically reflected in your app.

For implementation details and examples, see the Atlassian icon and Atlassian tile component documentation.

The Connect Inspector service is moving to open source and also being deprecated. This service will no longer allow the creation of new temporary apps. Already registered temporary apps will stop recording new events, and old events will be deleted. Any apps already installed on developer sites will not be uninstalled.

We’ve added a new rovo.isEnabled method to the Forge UI bridge API. This method returns a boolean indicating whether Rovo is enabled for the tenant. You can use it alongside the existing rovo.open method to conditionally invoke Rovo only when it’s available.

For more information, see the updated documentation for the Rovo bridge methods.

We've added optional height and width properties to the Frame component in UI Kit. Apps can now set explicit dimensions in pixels or percentages, instead of relying on automatic resizing. This gives you more control over your app's layout.

For more information, see the updated documentation for the Frame component.

We've updated the behavior of the Create work type API. Previously, creating a work type automatically added it to the Default Work Type Scheme. This is no longer the case.

What's changing

• Creating a work type no longer automatically associates it with the Default Work Type Scheme

• You must explicitly associate work types to work type schemes using the Associate work type to a work type scheme API

What you need to do

If your integration relies on newly created work types being automatically available in the Default Work Type Scheme, update your code to explicitly associate work types after creation:

1. Create the work type using the Create work type API

2. Associate the work type to the desired work type scheme using the Associate work type to a work type scheme API

This change is not backward-compatible. Integrations that relied on automatic association may need updates to ensure work types are properly associated with schemes.

For more information, see:

• Work types in the Jira Platform REST API documentation

• Work type schemes in the Jira Platform REST API documentation

• Community post: Project fields association improvements for additional context

Related: CHANGE-2527 (deprecation notice)

Rollout : IN PROGRESS

This change log ticket is a followup to https://ecosystem.atlassian.net/browse/CHANGE-2527 (where we announced a deprecation whereby all new fields now needed to be added to projects explicitly when created via API).

• Create custom field: will no longer implicitly associate the field with all projects. It needs to be associated with the required contexts using the Create associations API.

A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-127-jira-software-cloud-api-changes-improving-scalability-for-software-space-issue-results/98871

We've updated the behavior of the Delete work type scheme API. Previously, you could delete work type schemes even when they were associated with projects. This is no longer allowed.

What's changing

• Work type schemes that are associated with one or more projects can no longer be deleted

• The Delete work type scheme API will return a validation error if you attempt to delete a scheme that is associated with projects

What you need to do

If you need to delete a work type scheme that is currently associated with projects, you must first reassign all projects to a different scheme:

1. Use the Get work type scheme API with the projects expand and id query parameter to get a list of projects associated with the scheme you want to delete

2. Use the Assign work type scheme to a project API to reassign all associated projects to another work type scheme

3. Once all projects have been reassigned, you can delete the unused scheme using the Delete work type scheme API

This change is not backward-compatible. Integrations that attempt to delete work type schemes associated with projects will now receive validation errors and must be updated to follow the migration steps above.

For more information, see:

• Work type schemes in the Jira Platform REST API documentation

• Community post: Project fields association improvements for additional context

Related: CHANGE-2527 (deprecation notice)

You can now set custom colors for UI Kit Visualisation charts. You can either set a color theme or assign colors to attributes. This can be done by passing the prop colorPalette into your chart.

For an example of how to implement this, please see the Forge UI Kit example app at https://bitbucket.org/atlassian/ui-kit-charts-example/src/master/.

For more information, see documentation.