This page includes release notes and updates for Confluence Cloud app developers. Use this page to keep track of upcoming changes, deprecation notices, new features, and feature updates from Confluence Cloud.
For updates about changes to the Forge platform, see the Forge changelog in the Forge documentation.
You can also ask questions and learn from other Confluence Cloud developers on the Atlassian Developer Community.
In 6 months on Feb 25, 2027, app macros will only appear in one category in the modal element browser, and the categories ([string]) property will be fully replaced by a new category (string) property for Forge app macros.
Furthermore, we’re updating both the slash menu element browser and modal element browser to improve discoverability of our shared offerings, expected to begin rollout on Oct 6, 2026.
These changes impact all apps using macros and require action. Read More details below for more information on what’s changing, action required, and timelines.
All apps using Macros. Learn more about app macros at the following links.
https://developer.atlassian.com/platform/forge/manifest-reference/modules/macro/
https://developer.atlassian.com/cloud/confluence/modules/dynamic-content-macro/
https://developer.atlassian.com/cloud/confluence/modules/static-content-macro/
categories ([string]) property will be fully replaced by a new category (string) property for Forge app macrosToday, app macros can set an optional categories ([string]) property that defines which categories (potentially multiple) the app macro should appear in within the modal element browser (not the slash menu element browser).
In 6 months on Feb 25, 2027, all app macros will only be able to appear in one category in the modal element browser instead of multiple categories like they can today, to improve end users' browsing experience.
Since we are moving toward one category per app macro to improve the browsing experience, we have introduced a new category (string) property, where developers can define one valid category string to determine where their app macro shows up in both the modal element browser and slash menu element browser. Valid category inputs for this field will be:
structure (Native examples: Action item, Table, Status)
media (Native examples: Image, video, or file, Link, Emoji)
embed (Native examples: like Google Drive, Figma, Dropbox)
text-formatting (Native examples: Bullet list, Heading 1, Quote)
data-and-charts (Native examples: Database, Jira work items, Child items)
To learn more about these new categories, read the second part of this announcement.
On Feb 25, 2027, the categories ([string]) property will no longer be recognized by Forge app macros. It will effectively be fully replaced by this new category (string) field, making it so Forge app macros only appear in one category. Make sure to update the category (string) property by then to explicitly set which category you’d like your app macro to live in. Otherwise, if there is no valid entry in the category (string) property by then, your app macro will appear in an “Other elements” category as well as the default “All” category.
On Feb 25, 2027, Connect app macros will only appear in the first category listed in their categories ([string]) property with the below mapping. Connect app macros will not gain access to the new category (string) property.
formatting, confluence content, navigation, admin → structure
reporting, development → data-and-charts
media, visuals, communication → media
external-content → embed
No valid categories provided → Other elements (as well as the default "All" category)
Before the above deprecation on Feb 25, 2027, we will also be updating the categories & appearance of the slash menu element browser and modal element browser to improve discoverability of our shared offerings, expected to begin rollout on Oct 6, 2026. We will be:
Updating the set of categories we have to better capture our shared offerings.
Updating the slash menu element browser to actually show the categories.
Updating the modal element browser to show the new categories.
Cosmetically modernizing the slash menu and modal element browser.
Example of new categories in slash menu element browser
Example of new categories in modal element browser
Before this release, the valid set of categories app macros could use were:
Formatting - formatting
Confluence content - confluence-content
Navigation - navigation
Admin - admin
Reporting - reporting
Development - development
External content - external-content
Media - media
Visuals and images - visuals
Communication - communication
After this release, the new valid set of categories app macros can use will be the following. Any of the above categories not listed below will be considered legacy categories.
Structure - structure (Native examples: Action item, Table, Status)
Media - media (Native examples: Image, video, or file, Link, Emoji)
Embed - embed (Native examples: like Google Drive, Figma, Dropbox)
Text formatting - text-formatting (Native examples: Bullet list, Heading 1, Quote)
Data and charts - data-and-charts (Native examples: Database, Jira work items, Child items)
Any app macros with legacy categories still listed in their categories property on Oct 6, 2026 will have their categories automatically mapped to new categories in product with the below mapping.
formatting, confluence content, navigation, admin → structure
reporting, development → data-and-charts
media, visuals, communication → media
external-content → embed
No valid categories provided → Other elements (as well as the default "All" category)
If, however, you would like your app macro to appear in different categories than it would automatically be mapped to, update the new aforementioned category (string) property with any one of the new categories (available only for Forge app macros) by Oct 6, 2026.
As mentioned in the first part of this announcement, app macros will continue to be able to appear in multiple categories in the modal element browser for 6 months until Feb 25, 2027 , when app macros will begin to appear in only one category.
In the slash menu element browser, however, with very limited screen real estate, app macros will only appear in one category upon release on Oct 6, 2026. Furthermore, we plan to show up to 30 items per category in the slash menu element browser. If there are more items, we’ll show a “View more” CTA that leads to the modal element browser where all items appear. However, to ensure app macro discoverability, we will always show up to 10 app macros (if they exist) in a category in addition to the 30 item maximum. In the future, we will explore more dynamic behavior here.
For Forge app macros, this category will be determined by the category (string) property if available, or the first category listed in categories ([string]) as a fallback until Feb 25, 2027, when categories ([string]) will no longer work.
For Connect app macros, this category will be determined by the first category listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.
To ensure your app macro appears in an accurate category as we roll out these changes, we strongly recommend updating the new category (string) property (available for use by developers now) with one of the new valid categories below by Oct 6, 2026, when we begin to rollout the modernized element browser experience.
If not by Oct 6, 2026, be sure to update the new category (string) property by Feb 25, 2027 to ensure your app is assigned a category when categories [(string)] is no longer recognized. Otherwise, it will be shown in “Other elements” as well as the default “All” category.
Valid categories:
Structure - structure (Native examples: Action item, Table, Status)
Media - media (Native examples: Image, video, or file, Link, Emoji)
Embed - embed (Native examples: like Google Drive, Figma, Dropbox)
Text formatting - text-formatting (Native examples: Bullet list, Heading 1, Quote)
Data and charts - data-and-charts (Native examples: Database, Jira work items, Child items)
To help developers plan, here is a simplified timeline of the upcoming changes.
Between now and Oct 6, 2026:
In the slash element browser: All app macros will continue to appear as they do today.
In the modal element browser: All app macros will continue to appear in the macro element browser in any valid legacy categories listed in categories ([string]). The new category (string) property will not be used in product until then.
On and after Oct 6, 2026, and before Feb 25, 2027:
Forge app macros will:
In the slash element browser: Appear only in one category determined by the category (string) property – or, the first category listed in categories ([string]) as a fallback if no valid category (string) is set.
In the modal element browser: Appear either in one category determined by the category (string) property – OR in one or multiple categories listed in categories ([string]) as a fallback (with above mapping between legacy and new categories) if no valid category (string) is set.
Connect app macros will:
In the slash element browser: Appear only in one category determined by the first category listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.
In the modal element browser: Appear in one or multiple categories listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.
On and after Feb 25, 2027:
Forge app macros will:
In the slash element browser: Appear only in one category determined by the category (string) property. categories ([string])will no longer work or be recognized.
In the modal element browser: Appear only in one category determined by the category (string) property. categories ([string])will no longer work or be recognized.
Connect app macros will:
In the slash element browser: Appear only in one category determined by the first category listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.
In the modal element browser: Appear only in one category determined by the first category listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.
We highly recommend moving to Forge and following the above steps for Forge apps. Otherwise, no work is required for Connect apps, as Connect app macros will not gain access to the new category (string) property nor be able to update their categories ([string]) property.
Lastly, thank you for giving valuable feedback on RFC-140: Updating categories in the editor’s element browser about this topic.
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-140-updating-categories-in-the-editors-element-browser/101855
We are deprecating the workflowId field in the webhook payloads sent to Connect workflow Post Functions. This field now returns a placeholder value, and will be removed after 31 July 2027.
The workflowId is an invalid value and may lead to bugs in your applications if used. It references an internal identifier that does not correspond to a workflow and cannot be mapped to any workflow in our public APIs.
If you are using workflowId, you should instead use workflowName or workflowEntityId, both of which contain values that can be used to correctly identify workflows.
What's changing
The workflowId field in webhook payloads triggered from Connect workflow Post Functions now returns a placeholder value. The field will remain in the payload until it is removed after 31 July 2027, but its value should not be relied upon.
Why
The workflowId value references an internal identifier that does not correspond to a workflow. It cannot be used to query or identify workflows through our public APIs, and using it can cause unexpected behaviour or bugs in your app.
What you need to do
Before 31 July 2027:
• Identify any integrations that read workflowId from these webhook payloads.
• Replace usages of workflowId with workflowName or workflowEntityId.
See example connect trigger below:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
"configuration": {
"value": "Configuration from the post function edit page"
},
"issue": {
"fields": {
...
},
"id": "10000",
"key": "TEST-1",
"self": "http://issues.example.com/jira/issue/10000"
},
"transition": {
"from_status": "Open",
"to_status": "Resolved",
"transitionId": 5,
"transitionName": "Resolve Issue",
"workflowId": 99999, <-- deprecated, no longer used.
"workflowName": "example workflow"
"workflowEntityId": "<some UUID>" <-- newly added, should be used.
}
}
We are deprecating the workflowId field in the webhook payloads sent via the Trigger a webhook post function in Jira workflows. This field now returns a placeholder value, and will be removed after 31 July 2027.
The workflowId is an invalid value and may lead to bugs in your webhook handlers if used. It references an internal identifier that does not correspond to a workflow and cannot be mapped to any workflow in our public APIs.
If you are using workflowId, you should instead use workflowName or workflowEntityId, which contains a value that can be used to correctly identify workflows.
What's changing
The workflowId field in webhook payloads sent via the Trigger a webhook post function now returns a placeholder value. The field will remain in the payload until it is removed after 31 July 2027, but its value should not be relied upon.
Why
The workflowId value references an internal identifier that does not correspond to a workflow. It cannot be used to query or identify workflows through our public APIs, and using it can cause unexpected behaviour or bugs in your webhook handlers.
What you need to do
Before 31 July 2027:
• Identify any integrations that read workflowId from these webhook payloads.
• Replace usages of workflowId with workflowEntityId.
See the example shape of a webhook below (or read the relevant documentation here: https://developer.atlassian.com/cloud/jira/platform/webhooks/#webhook-payload )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
"timestamp": 1606480436302,
"webhookEvent": "jira:issue_updated",
"issue_event_type_name": "issue_generic"
"user": {
...
},
"issue": {
--> See Issue shape in table below
},
"transition" : {
"from_status": "Open",
"to_status": "Resolved",
"transitionId": 5,
"transitionName": "Resolve Issue",
"workflowName": "example workflow"
"workflowId": 99999, --> this is now a placeholder value
"workflowEntityId": "<some UUID>" <-- newly added, should be used.
}
We’re adding the workflowEntityId to webhook payloads sent to Connect applications to trigger post functions - this ID can be used to perform workflow operations or query data using the Workflow Rest APIs
The transition object will now contain a entry for the workflowEntityId.
See example below:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
"configuration": {
"value": "Configuration from the post function edit page"
},
"issue": {
"fields": {
...
},
"id": "10000",
"key": "TEST-1",
"self": "http://issues.example.com/jira/issue/10000"
},
"transition": {
"from_status": "Open",
"to_status": "Resolved",
"transitionId": 5,
"transitionName": "Resolve Issue",
"workflowId": 99999, <-- deprecated, no longer used.
"workflowName": "example workflow"
"workflowEntityId": "<some UUID>" <-- newly added, should be used.
}
}
We’re adding the workflowEntityId to webhook payloads that are sent as part of workflow post function execution - this ID can be used to perform workflow operations or query data using the Workflow Rest APIs
The transition object will now contain the workflowEntityId field.
See the example shape of a webhook below (or read the relevant documentation here: https://developer.atlassian.com/cloud/jira/platform/webhooks/#webhook-payload )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
"timestamp": 1606480436302,
"webhookEvent": "jira:issue_updated",
"issue_event_type_name": "issue_generic"
"user": {
...
},
"issue": {
--> See Issue shape in table below
},
"transition" : {
"from_status": "Open",
"to_status": "Resolved",
"transitionId": 5,
"transitionName": "Resolve Issue",
"workflowName": "example workflow"
"workflowId": 99999, --> this is now a dummy unusable value
"workflowEntityId": "<some UUID>" <-- newly added, should be used.
}
As per our previous announcement, we will be progressing admin-facing migration messaging on the Connected Apps page from the Developer Canary Program to production instances. This rollout will begin in approximately two weeks.
The following app categories will receive admin-facing messaging:
Apps that have declared connectToForgeMigration with a migration intent of "no"
Apps that have declared connectToForgeMigration with a migration intent of "unsure"
Apps that have not adopted the connectToForgeMigration module
Apps without a Forge manifest (i.e., Connect apps)
Apps that have declared connectToForgeMigration with an intent of "yes" are estimated to begin receiving admin messaging in mid-August. We will provide another changelog entry at least 2 weeks before that change proceeds.
End-user messaging will not be included in this initial rollout. When ready, we'll follow the same approach:
Release to Developer Canary tenants first for early testing
Roll out in staggered cohorts
Provide at least 2 weeks advance notice via the Forge changelog before each rollout stage goes live
Adopt the connectToForgeMigration module in your Forge manifest for each major version of your app (https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-to-forge-migration-module/).
Declare your migration intent as this determines which cohort your app falls into and when messaging appears.
Provide a migration URL. This URL will be surfaced directly in customer-facing notices, replacing the default Atlassian messaging with your app-specific guidance.
Preview the experience now using the Developer Canary Program. Customer messaging is already live on canary tenants. Install your app on a canary instance, navigate to the Connected Apps page, and confirm your migration URL renders as expected before the production rollout reaches your cohort.
Apps that are blocked by an accepted Connect EOS FRGE ticket will be exempt from customer messaging until one month past the delivery date of the blocking feature. This exemption list is determined exclusively by partners who have submitted a Connect EOS Submission request on these accepted tickets, providing a valid use case and explanation. If an app utilises an affected feature but has not submitted a Connect EOS submission, it will not be exempted from this messaging.
For the full customer-facing experience (including more information on what admins will see), please visit the documentation here. This page will also be shortly updated to capture our rollout approach.
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.
Resource-restricted tokens are now available for all developers creating new 3LO apps.
When creating a new OAuth 2.0 (3LO) app via the Developer Console, you can now opt in to resource-restricted tokens. This ensures that access tokens issued for your app are scoped to only the specific Atlassian site a user explicitly selects during consent rather than granting broad access across all sites.
The onboarding guide for Resource restricted apps is available here:
https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/#oauth-2.0-(3lo)-apps
We've added a new set of public REST API endpoints that let you migrate Confluence spaces from the legacy granular space permission model to role-based access control (RBAC) using space roles.
Confluence spaces historically used 14 granular permissions (e.g. Add page, Delete attachment, Set permissions) assigned directly to users and groups. This checkbox-based model is difficult to audit, bulk-manage, and keep consistent across hundreds of spaces.
Confluence is replacing this with role-based access control (RBAC), where each principal (user, group, or app) is assigned a single space role (e.g. Admin, Collaborator, Viewer) that bundles the relevant permissions together.
These endpoints are the programmatic migration path: they let Confluence admins convert existing granular permission grants into equivalent role assignments — in bulk, without manual remapping — and are designed to be called from scripts or admin tooling.
All endpoints are under /wiki/api/v2/space-permissions/transition:
GET /combinations — List a space's permission combinations that don't yet map to a role
POST /combinations — Generate the permission combinations for a space
POST /role-assignments — Bulk assign space roles to users/groups based on their existing permission combinations
POST /access-removals — Bulk remove legacy permission combinations after transitioning to roles
GET /tasks/{taskId} — Check the status of a transition task
read:configuration:confluence — for the GET endpoints
write:configuration:confluence — for the POST endpoints
Calling these endpoints requires Confluence site admin permission.
POST /combinations — compute the permission combinations currently in use across a space's grantees (returns a taskId)
Poll GET /tasks/{taskId} until COMPLETED
GET /combinations — list the combinations that aren't yet mapped to an RBAC role
POST /role-assignments — bulk assign roles so existing users and groups retain equivalent access under the new model
POST /access-removals — bulk remove the legacy permission grants that have been superseded by role assignments
Poll GET /tasks/{taskId} for the assignment / removal tasks until COMPLETED
These endpoints are experimental. We're validating the API contract against real-world migration workloads and plan to stabilize it once we've confirmed the shape holds across a range of tenant configurations.
Available now in all Confluence Cloud editions in roles transition mode. Please raise issues on the Atlassian Developer Community if you find anything.
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.
What’s changing:
The Confluence Cloud REST API v2 endpoints for listing page and blogpost versions now enforce a maximum limit of 50 results when the body-format query parameter is included. Requests without a body-format parameter are unaffected.
Affected endpoints:
• GET /wiki/api/v2/pages/{id}/versions
• GET /wiki/api/v2/blogposts/{id}/versions
Previously, requests with body-format could return up to 250 results. If the requested limit exceeded the maximum, the API returned a 400 Bad Request error.
With this change, if the requested limit exceeds 50 when body-format is specified, the response will be capped at 50 results and return 200 OK.
What you need to do:
If your integration relies on receiving more than 50 versions in a single request with a specific body format, you must update your logic to handle pagination. Use the cursor provided in the _links.next field of the response to fetch subsequent pages of results.
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.
A new RFC is ready for review at RFC-136
Rate this page: