Changelog

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.

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

The new customerServiceManagement:crmImport Forge module is generally available from June 30, 2026.

What's changing

This module allows you to add an item under the Manage dropdown on the Customers, Organizations, and Products pages within the customer directory of the Customer Service Management (CSM) app. When a user clicks the item, your app renders content inside a modal dialog.

This extension point is specifically designed for apps that import customer context data from external CRM systems into Customer Service Management, providing a dedicated UI entry point for these integrations.

What you need to do

To start using this module, refer to the customerServiceManagement:crmImport manifest reference for technical configuration and schema details.

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.

On 15 September 2026, the jiraServiceManagement:queuePage Forge extension point will stop loading on Customer Service Management (CSM) spaces in Jira.

What's changing

Apps using this module on CSM queues will stop rendering on that surface from the deprecation date. The module will continue to function as expected on standard Jira Service Management (JSM) spaces.

What you need to do

You should migrate to the dedicated replacement extension point, customerServiceManagement:queuePage, which is generally available from 15 June 2026.

• Replace jiraServiceManagement:queuePage with customerServiceManagement:queuePage in your app's manifest.yml.

• Review the manifest reference for the new module.

• Deploy your changes before the deadline.

Timeline

• 15 June 2026: customerServiceManagement:queuePage reaches GA.

• 15 June 2026 – 14 September 2026: Migration window.

• 15 September 2026: jiraServiceManagement:queuePage stops loading on CSM spaces.

If you cannot migrate in time, please contact Atlassian for case-by-case support.

The new customerServiceManagement:queuePage Forge module is generally available from 15 June 2026.

What's changing

This module lets you add a custom item under the Queues section in the left navigation of a Customer Service Management (CSM) space. When clicked, your app renders a full page within the Jira interface.

What you need to do

• Review the customerServiceManagement:queuePage manifest reference for configuration details.

• If you currently use jiraServiceManagement:queuePage on CSM spaces, you must migrate to this new dedicated extension point.

Related deprecation

As a result of this new dedicated extension point, the existing jiraServiceManagement:queuePage Forge extension point will no longer load on CSM spaces from 15 September 2026. See CHANGE-3175 for migration details.

The new customerServiceManagement:requestDetail Forge module is generally available from 15 June 2026.

What's changing

This module lets you add a panel to the request details screen of a Customer Service Management (CSM) support site. Your app's content is displayed below the Conversation history section on the request details page.

What you need to do

Refer to the customerServiceManagement:requestDetail manifest reference for technical configuration and schema details.

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

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

The Revoke portal-only access for user JSM API is now generally available (GA). We have removed the experimental flag, meaning the API will no longer be modified without prior notice.

What's changing

• GA Status: The API is no longer experimental.

• Error Handling: We've updated the status code from 400 to 404 when a passed accountId does not exist.

What you need to do

If you are currently using this API, update your error handling to account for the new 404 status code when a user is not found. You can find the full technical details in the Jira Service Management Cloud REST API documentation.