Changelog

The Bulk fetch issues API (POST /rest/api/3/issue/bulkfetch) now supports a maximum of 1000 issues in a single request, up from the previous limit of 100. This higher limit is available for requests optimized for efficient processing. https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/1-000-Issues-One-Call-Bulk-Fetch-Gets-a-10-Boost/ba-p/3281867

What's changing
To qualify for the 1000-issue limit, your request must meet the following criteria:

• Explicit field selection: You must explicitly name at least one field to include. Wildcards like *all or *navigable, and requests containing only exclusions (e.g., -description), are not eligible.

• Field count: No more than 100 fields can be explicitly included.

• Single-value fields only: Included fields must not return multiple values (e.g., comment, worklog, or attachment are excluded).

• Restricted expands: The expand parameter must not include changelog, editmeta, operations, renderedFields, transitions, or versionedRepresentations.

What you need to do
No action is required if you wish to continue using the existing 100-issue limit. To take advantage of the 1000-issue capacity:

• Update your request payload to explicitly list the specific fields you need.

• Remove any multi-value fields or restricted expand parameters.

• Increase your batch size up to 1000 issueIdsOrKeys.

If you require multi-valued data or changelogs for a large set of issues, we recommend splitting the work: use one 1000-issue call for "cheap" fields and separate, narrower calls for complex data. For changelogs, use the Bulk fetch changelogs endpoint to avoid the 40-item cap imposed by expand=changelog.

For more details, see the Bulk fetch issues reference documentation.

What's changing

Forge apps can now provide custom search suggestions for searchAlias properties of Forge object custom fields.

If your app already uses searchSuggestions, you can enable it for a specific alias by setting searchSuggestionsEnabled: true on the object schema property that defines that searchAlias. When users write JQL against that alias, Jira will show app-provided suggestions instead of default indexed values.

What you need to do

If your Forge object custom field already uses searchSuggestions and you want those suggestions to apply to a searchAlias:

• Update your app's manifest to set searchSuggestionsEnabled: true on the schema property that defines the alias.

• Ensure your searchSuggestions function is configured to handle requests for the alias.

No action is needed if your app doesn’t use search aliases, or if you want aliases to keep using Jira’s default autocomplete.

For more information, consult the https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field reference documentation.

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

Following the deprecation announcement last year, access to the old workflow editor will be removed for all customers starting July 13, 2026.

What you need to do

• Review your apps: If you own workflow-related apps, ensure your rules provide a high quality experience in the new editor.

• Implement rule descriptions: We recommend providing dynamic configuration descriptions for Forge and Connect workflow rules. This helps admins understand your app's rules at a glance within the new editor.

• Test and report issues: If you encounter any behavior issues in the new workflow editor, please raise a support ticket.

For more details refer to the community announcement.

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.

We’re enhancing the jira:uiModifications module to support interactions with different user types in Jira.

Apps with UI Modifications that need to work for anonymous users must explicitly declare this in the app manifest using the unlicensedAccess attribute.

This change will take effect on Jun 29, 2026. We recommend that you deploy an update to your app before this date to avoid any interruption to your app’s functionality for anonymous users.

Add the anonymous value to the unlicensedAccess attribute for each jira:uiModificationsmodule that needs to execute for anonymous users in Jira.

For more information, see the guide on Access to Forge apps for unlicensed users.

From Monday Jun 29, 2026 onwards, UI Modifications modules will not be executed for anonymous users unless the module explicitly declares it.

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.

What's changing

Forge custom fields (FCF) of type object can now render a rich custom edit experience in Jira's bulk edit.

Previously, object type FCF were rendered as an empty text input via (Atlaskit's TextField). With this change,

• It will be rendered as an empty JSON schema, making it easier to inline edit.

• You can now control how the field renders during bulk edit using your own custom resources via UI Kit or Custom UI, consistent with other surfaces such as issue view and global issue create.

This is available as a Preview feature, and currently only for the object field type.

What you need to do

• To opt in to the bulk edit experience, add issue-bulk-edit to the edit experiences of your custom field (or custom field type) in your manifest.yml:

  1 2 3 4 5 6 7 8 9 10 modules: jira:customField: - key: my-object-field name: My object field type: object edit: experience: - issue-create - issue-transition - issue-bulk-edit // <-- new surface

• Keep these constraints in mind for the bulk edit experience:

  • Issue and Project details are not available in the extension context during issue-bulk-edit.

  • In the formatter expression, only value and fieldId are available when renderContext/experience is issue-bulk-edit.

  • If your edit UI depends on issue or project context, detect this case using renderContext === 'issue-bulk-edit' and render an appropriate fallback UI.

For details, see: Jira Custom Fields > Issue Bulk Edit.

Forge apps using the UI Modifications API configured for Issue View will now have their modifications applied when issues are opened via ViewIssueModal (for example, from global pages, admin pages, or custom UI panels).

Previously, UI Modifications were not loaded silently in this context. This applies to all supported project types, and requires no changes to your app's manifest or code

For more details, see the Jira UI modifications documentation.

As recently announced in Raising the bar on Marketplace cloud app security: together we are updating the Marketplace Security Bug Fix Policy to shorten vulnerability remediation timelines for Marketplace cloud apps. These changes ensure a higher security standard across our ecosystem.

What’s changing
The remediation Service Level Objectives (SLOs) for Marketplace cloud apps are being shortened. The timelines for Data Center apps remain unchanged.

Updated Cloud App SLOs (Enforceable September 1, 2026):

• Critical: 10 days

• High: 4 weeks

• Medium: 12 weeks

• Low: 25 weeks

Data Center App SLOs (Unchanged):

• Critical: 12 weeks

• High: 12 weeks

• Medium: 12 weeks

• Low: 25 weeks

Additionally, we have published the Marketplace Security Enforcement Policy, a consolidated source of truth for marketplace security compliance expectations, including vulnerability management, OAuth compliance, partner verification, bug bounty participation, and incident response.

What you need to do

• Review the new timelines: Ensure your internal processes are updated to meet the new cloud app SLOs by September 1, 2026.

• Check your tickets: We have corrected an issue where some AMS Data Center tickets incorrectly showed cloud remediation dates. If you believe a ticket still has an incorrect date, please raise an ECOHELP ticket.

• Watch the policy page: The Marketplace Security Enforcement Policy is a living document, we recommend "watching" the page for future updates.

We've introduced the Tile component for Forge UI Kit apps, now available in Preview. The Tile component is a rounded square container for displaying assets like emojis, or objects in a consistent, styled way.

The component supports various sizes (from 16px to 48px), customizable background colors using design tokens, optional borders, and adjustable internal padding for different asset types including third-party logos.

For implementation details and examples, see the Tile component documentation.

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

Forge custom fields can no longer be edited through the legacy bulk edit wizard (/secure/views/bulkedit/BulkEditDetails.jspa). On the legacy screen, they now appear under Unavailable actions with a redirect message.

Forge custom fields remain fully supported in the new bulk edit experience, available from the list view, backlog view, and JQL search page.

We are announcing the deprecation of https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-issue-glance/ (jira:issueGlance), as we have replaced with https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-issue-context/ (jira:issueContext) module. The Jira Issue Glance module will soon be removed from the work items completely.

Please refer to the following documentation for more details - https://developer.atlassian.com/cloud/jira/platform/future-proof-issue-glance-implementation/

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.