Changelog

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.

Forge SQL now inspects every query submitted by your app before it reaches the database. Queries that contain restricted functions, statements, or syntax are rejected with a new SQL_POLICY_VIOLATION error code before execution.

We’ve implemented this new policy to enforce the following:

• Stricter compliance with standard ANSI SQL syntax.

• Pre-emptive protection against SQL-based resource exhaustion and exploits.

• Stable, predictable performance across all Forge apps using SQL storage.

New error code: SQL_POLICY_VIOLATION

If your app submits a query that uses a restricted function or pattern, the @forge/sql package will return an error with a code, message, and suggestion field to help you resolve the violation.

Restricted functions and statements

The following are now monitored and may trigger rejection:

• Functions: SLEEP(), BENCHMARK(), COMPRESS(), UNCOMPRESS(), AES_ENCRYPT(), AES_DECRYPT(), SHA2()

• Statements: ALTER USER, LOCK TABLES, USE <table>

• Patterns: Unsupported optimizer hints, SET GLOBAL/SET INSTANCE, most SHOW statements, SQL-level PREPARE/EXECUTE/DEALLOCATE PREPARE, and multi-statement queries.

A subset of SET, SHOW, USE and optimizer hints remain permitted. See the SQL query policy documentation for the full allowlist.

What you need to do

• Review your queries: If your app uses any restricted functions or syntax patterns, those queries will now be rejected at runtime.

• Update error handling: Check for errorCodes.SQL_POLICY_VIOLATION alongside existing error codes to handle rejections gracefully.

If your app requires a restricted function for a valid use case, request an exemption through the Developer Support portal with your app.id, the query, and the use case.

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.

You can now configure product event triggers and scheduled triggers to skip invocations for installations where your app is not actively licensed.

What's changing

By adding the appIsLicensed filter to your trigger modules in manifest.yml, the Forge platform will block trigger invocations for installations where the app's license is already inactive. This helps reduce unnecessary compute usage for unlicensed installations.

This change is specifically designed to address apps with existing inactive licenses (e.g., legacy entitlements that have lapsed). It is separate from the broader platform app suspension behaviour being explored in https://community.developer.atlassian.com/t/rfc-137-forge-app-suspension-behaviour/101092, which covers future suspension lifecycle handling.

This is an opt-in feature. Existing triggers are unaffected unless you explicitly add the filter to your manifest.

What you need to do

To enable this filtering, update your manifest.yml by adding the appIsLicensed: true filter to your trigger modules:

• Open your manifest.yml file

• Locate your trigger or scheduledTrigger modules

• Add the filter property with appIsLicensed: true

For more information, see the https://developer.atlassian.com/platform/forge/manifest-reference/modules/trigger/#filter-reference and https://developer.atlassian.com/platform/forge/manifest-reference/modules/scheduled-trigger/#filter-reference.

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.

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.

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.

What's changing
We've added new error handling documentation for Forge Realtime. This covers expected error patterns and recommended handling strategies for all realtime operations:

• publish

• subscribe

• signRealtimeToken

The new guidance includes details on:

• Rate limit errors: How to identify and respond when your app exceeds Realtime service limits.

• Token pre-validation errors: Troubleshooting issues during the token signing and validation process.

• Common failures: A catalog of other frequent error scenarios with actionable recovery steps.

What you need to do
Review the new https://developer.atlassian.com/platform/forge/realtime/error-handling-for-realtime-methods/ documentation to ensure your app gracefully handles these scenarios. We recommend implementing the suggested retry logic and validation checks to improve your app's reliability.

A new Rovo-powered AI chat widget is now available for all logged-in users on https://developer.atlassian.com. Located in the bottom right corner of developer documentation pages, this assistant can answer questions, surface relevant docs, and help you build on the platform faster.

Key features include:

• Contextual answers: The chat understands the context of your question and provides relevant answers rather than generic search results.

• Developer-focused knowledge: Trained on Atlassian developer documentation, the assistant understands Forge, REST APIs, Marketplace, and platform concepts.

• Natural language understanding: Ask questions in plain language; no need to know exact documentation titles or keywords.

• Follow-up questions: Continue a conversation naturally with follow-up questions to drill deeper into a topic.

• Source transparency: The widget displays the specific documentation and support sources used to generate each answer.

• Conversation history: You can access and review your previous interactions for up to 28 days.

• Independent operation: The assistant works independently of your product licenses and organization-level AI settings.

For more details on how the assistant handles data and what sources it uses, see the Atlassian developer AI chat documentation.

You can now use Jira entity properties (issue, project, and user) to filter Forge trigger events and include them in the delivered event payload. This allows your app to process only relevant changes and reduces unnecessary executions.

What’s changing

• Entity property filtering: You can now define expressions in your manifest.yml that use Jira entity properties to filter events before they trigger your app.

• Payload enrichment: Relevant entity properties can now be included directly in the event payload, eliminating the need for additional REST API calls to fetch this data.

What you need to do

• Update your manifest.yml to include expression filters using entity properties.

• Update your event handlers to utilize the enriched payload data.

• For more information, see the Forge Trigger module reference.

Customer-managed egress and remotes in Forge is now available in Preview. This feature enables apps to dynamically declare egress and remotes post-installation, giving site administrators control over where apps can send and receive data.

Apps using customer-managed egress and remotes can now be used in production environments.

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!