This page includes release notes and updates for Jira Cloud app developers. Use this page to keep track of upcoming changes, deprecation notices, new features, and feature updates from Jira Cloud Platform.
For updates about changes to the Forge platform, see the Forge changelog in the Forge documentation.
Go to our developer community to ask questions. You may also be interested in the What's New blog for Atlassian Cloud where details of major changes that affect all users of the Jira Cloud products are announced.
The functionality to filter and update draft workflows using the Workflow transition rules APIs will be discontinued on Nov 2, 2026. This change coincides with the removal of the legacy workflow editor in Jira Cloud, as announced in the sunsetting of the old workflow editor which begins from June 11, 2026.
The following endpoints are affected when they are used to work with draft workflows:
GET /rest/api/3/workflow/rule/config (Retrieve workflow rule configuration)
PUT /rest/api/3/workflow/rule/config (Update workflow rule configuration)
DELETE /rest/api/3/workflow/rule/config/delete (Delete workflow rule configuration)
After this change:
Requests that attempt to filter or modify a draft workflow (for example, by setting draft=true in query parameters or request bodies) will receive an HTTP 400 (Bad Request) response.
Responses containing WorkflowId objects will no longer include the draft attribute. Any request payloads that currently send workflowId.draft will be rejected.
Action required
Review your integrations for any use of the draft attribute in:
Query parameters (for example, draft=true on GET /rest/api/3/workflow/rule/config), and
Request or response handling of workflowId.draft.
Update your code to:
Stop passing the draft flag, and
Work exclusively with active workflows, using the latest workflow editor model (which no longer uses workflow drafts).
We’re announcing the deprecation and upcoming decommission of the AUI CDN.
AUI CDN will be shut down after Oct 30, 2026.
What is AUI CDN?
aui-cdn.atlassian.com hosts legacy JavaScript and CSS assets for AUI (Atlassian User Interface) versions 5.2.0 – 6.0.9.
Who is affected?
The AUI CDN is primarily used by Connect apps, so this mostly affects apps not yet migrated from Connect to Forge. Connect has announced its own End of Support late 2026. In some rare cases, AUI CDN is also used by Forge apps.
How to check if you're affected
Search your app's source code for any URLs containing aui-cdn.atlassian.com. If you find any references, your app is loading assets from AUI CDN and you need to take action before the shutdown.
What to do if you're affected
Remove all references to aui-cdn.atlassian.com from your codebase and migrate to a supported alternative:
Recommended: Migrate AUI to Atlassian Design System or Forge UI Kit. Any Atlassian Connect apps should also migrate to Forge, as Connect End of Support has been announced.
If migrating is not suitable for you (e.g. non-React apps), you have these options:
Bundle AUI directly: via npm. See the AUI documentation.
Third-party CDN: use a CDN that serves npm packages, e.g. jsDelivr (https://cdn.jsdelivr.net/npm/aui@latest/) or unpkg (https://unpkg.com/aui@latest/)
Self-host: download any required AUI assets and serve the static assets yourself
Timeline
AUI CDN will be shut down after Oct 30, 2026. After this date, any requests to aui-cdn.atlassian.com will fail, which will break apps that haven't migrated. Please migrate as soon as possible.
The legacy icon entry points in @atlaskit/icon have been permanently removed following the deprecation notice published in 2024. The removed entry points are: @atlaskit/icon/glyph/, @atlaskit/icon/core/migration/, @atlaskit/icon/utility/, @atlaskit/icon/base, @atlaskit/icon/svg, and @atlaskit/icon/migration-map.
The no-legacy-icons ESLint rule has also been removed from @atlaskit/eslint-plugin-design-system as it is no longer needed.
Apps using Forge Custom UI or Atlassian Connect that import from any of the above entry points must update their imports to use @atlaskit/icon/core/ instead. Migration guidance, codemods, and the full list of icon replacements were published in the original deprecation notice: https://developer.atlassian.com/changelog/#CHANGE-2773
What was removed
@atlaskit/icon/glyph/* — legacy SVG glyph icon components (~400 icons)
@atlaskit/icon/core/migration/* — migration shim components (~200 shims)
@atlaskit/icon/utility/* — 27 utility (12px) icon components
@atlaskit/icon/base and @atlaskit/icon/svg — legacy base components
@atlaskit/icon/migration-map — migration type helpers
no-legacy-icons ESLint rule from @atlaskit/eslint-plugin-design-system
What to use instead:
Import icons directly from @atlaskit/icon/core/*. The full icon replacement map instructions are in the original deprecation notice: https://developer.atlassian.com/changelog/#CHANGE-2773
What you need to do if you are using Forge Custom UI or Atlassian Connect:
Update any imports from the removed entry points to use @atlaskit/icon/core/* and bump @atlaskit/icon to the latest version.
What you need to do if you are using Forge UI Kit or Forge UI Kit 2:
Nothing. Icons in UI Kit are managed by Atlassian and are not affected by this change.
The spacing prop on icon components in @atlaskit/icon and @atlaskit/icon-lab is now deprecated. The prop was introduced to ease migration from the legacy icon system by allowing icons to carry their own padding. Now that the legacy icon migration is complete, whitespace around icons should be controlled by the surrounding layout rather than the icon itself — consistent with how the rest of the Atlassian Design System handles spacing.
The spacing prop will be removed in a future major release. While no immediate action is required and existing usages will continue to work for now, we recommend migrating away from spacing ahead of its removal. To migrate, replace spacing="spacious" or spacing="compact" with a Flex wrapper from @atlaskit/primitives/compiled using explicit padding tokens. A codemod and ESLint rule with IDE quick-fix are available to automate the migration. Full guidance: https://atlassian.design/components/icon/usage
Why is this being deprecated?
Spacing baked into an icon is invisible to parent components, making layout debugging harder.
The rest of the Atlassian Design System uses explicit layout primitives (Flex, tokens) to control spacing — the spacing prop is an outlier.
The internal implementation is incompatible with @atlaskit/css compiled styling patterns.
How to migrate
Before:
1
<AddIcon label="Add" spacing="spacious" />After:
1
2
3
4
5
6
7
8
9
10
11
12
import { cssMap } from '@atlaskit/css';
import { Flex } from '@atlaskit/primitives/compiled';
import { token } from '@atlaskit/tokens';
const iconSpacingStyles = cssMap({
space050: {
paddingBlock: token('space.050'),
paddingInline: token('space.050'),
},
});
<Flex xcss={iconSpacingStyles.space050}>
<AddIcon label="Add" />
</Flex>Migration tooling:
Codemod — run npx @atlaskit/codemod-cli and select icon-spacing-to-flex-primitive
ESLint rule — enable @atlaskit/design-system/no-icon-spacing-prop for IDE quick-fix suggestions
What you need to do if you are using Forge Custom UI or Atlassian Connect:
Migrate usages using the codemod or ESLint rule above. No immediate action needed — at least 6 months notice will be given before removal.
What you need to do if you are using Forge UI Kit or Forge UI Kit 2:
Nothing. The spacing prop is not exposed to Forge UI Kit developers.
As per CHANGE-2567, from Apr 2, 2026, the Get all workflows API has been removed from our public API. This API is no longer supported for public use.
We recommend transitioning Search workflows API for a more efficient and scalable alternative.
As previously announced in CHANGE-2568, the Create workflow API has been removed and is no longer supported. Calls to this endpoint will now result in a 404 Not Found error.
We recommend transitioning Bulk create workflows and Bulk update workflows.
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.
Following our deprecation notice on Sep 29, 2025:
Customers can no longer install Connect private apps.
Partners and developers can no longer update existing Jira or Confluence apps using a Connect descriptor on the Atlassian Marketplace.
Existing installations of Connect private apps will remain unaffected for now.
From now on, private apps can only be installed via Forge installation links. See https://developer.atlassian.com/platform/forge/distribute-your-apps/ for instructions on sharing these links to your customers.
This milestone is in line with our timeline for ending support for the Connect platform.
To continue providing updates to users of your Connect app, it must be migrated to Forge. You can start doing this without completely rewriting your app by incrementally adopting Forge from Connect.
Forge apps with app.connect.key declared in their manifest can now retrieve the Connect clientKey for an installation via a reserved, read-only app property. See Retrieving the Connect clientKey in Forge for instructions.
This capability is only being provided temporarily to facilitate migration away from the Connect installed lifecycle webhook, which previously was the only way to obtain the clientKey. It will only be supported for as long as Connect is supported. For more information about the timeline for Connect end-of-support, refer to this blog.
We've improved how errors from https://developer.atlassian.com/platform/forge/manifest-reference/modules/jql-function/ are surfaced to end users in Jira. This functionality will be rolled out for all customers in next 2 weeks.
Previously, when a custom JQL function returned an error, Jira treated it as a generic server error and End users would see a non-descriptive message — "We couldn't load your search results".
Now, errors returned by custom JQL functions are classified as JQL validation errors and displayed inline, just like native JQL errors. If your app returns a custom error message, that message is shown directly to the end user.
The jira:globalBackgroundScript module is now more powerful and adds following major functionality to the module -
Experience-based access control - Restrict which Jira views your script runs on using the experience property in the manifest. If no experience is specified, the script will not run anywhere.
Modal support - Open modal dialogs from a background script on any allowed view using the https://developer.atlassian.com/platform/forge/apis-reference/ui-api-bridge/modal/.
View context access - Access view-specific context such as issueKey, projectId, boardId, and project.type depending on the current Jira view.
Please read more here https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-global-background-script/.
We are pleased to announce the availability of multi-user app ownership for OAuth 2.0 (3LO) apps in the developer console.
Multiple admins - You can assign multiple admins to your OAuth 2.0 apps in the developer console.
Ownership transfer - The OAuth 2.0 app ownership transfer option is now available in the developer console.
We've introduced a new asynchronous bulk API that allows Jira administrators to pin or unpin Forge app issue panels to multiple projects in a single request — processing up to 1,000 projects at once.
For app developers: Integrate this API into your Forge app to give Jira admins a centralized view for managing issue panel visibility across projects. For full API details, see: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-panels/#api-rest-api-3-forge-panel-action-bulk-async-post
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):
To start testing, sign up for the EAP here.
Rate this page: