Changelog entry: CHANGE-3505
Published: Tue, 06 Oct 2026 01:09:30 GMT
Category: Announcement
Link: https://developer.atlassian.com/platform/forge/changelog/#CHANGE-3505
What is changing
Static macros for Confluence on Forge have moved from EAP to Preview (available in dev, staging, and production for early adopters). A static macro renders natively into the page HTML instead of an iframe: the app returns ADF or Confluence Storage Format nodes directly from its function/endpoint.
Key points from the entry:
- Native rendering: content becomes part of the page HTML, no iframe latency.
- Batch rendering: a
concurrency property lets one invocation process multiple macro instances. The render function receives an array of macro arguments and returns the corresponding ADF / Storage Format nodes.
- Export support: static macro output is included in PDF / Word page exports.
- Manifest: a new
static property on the macro module in manifest.yml.
What it likely means for forge-sim
Area: modules (manifest) + renderer/invocation.
- Manifest loader: accept and validate the new
static property (and concurrency) on macro modules. Today forge-sim treats every macro as a UI Kit / Custom UI surface with a resource + render; a static macro is function/endpoint-backed with no resource, so UI module detection needs to recognize the shape instead of flagging it as malformed.
- Invocation contract:
forge_ui_render / in-process macro rendering assumes a ForgeDoc tree. Static macros need a distinct path: build an array of macro-arg payloads (batched up to concurrency), call the function or remote endpoint, and surface the returned ADF / Storage Format nodes. Parity means rejecting a non-array return and honoring the batch shape.
- MCP / dev server:
forge-sim dev renders macros in an iframe; a static macro should render its ADF inline (or at least expose the raw nodes) so the local loop matches Confluence.
- Docs/capability matrix: add a row for static macros, marked Preview.
Nothing here alters existing documented macro behavior; it is an additive module shape. Confirm the exact static / concurrency schema and the argument/return payload against the static macros docs before implementing.
Changelog entry: CHANGE-3505
Published: Tue, 06 Oct 2026 01:09:30 GMT
Category: Announcement
Link: https://developer.atlassian.com/platform/forge/changelog/#CHANGE-3505
What is changing
Static macros for Confluence on Forge have moved from EAP to Preview (available in dev, staging, and production for early adopters). A static macro renders natively into the page HTML instead of an iframe: the app returns ADF or Confluence Storage Format nodes directly from its function/endpoint.
Key points from the entry:
concurrencyproperty lets one invocation process multiple macro instances. The render function receives an array of macro arguments and returns the corresponding ADF / Storage Format nodes.staticproperty on themacromodule inmanifest.yml.What it likely means for forge-sim
Area: modules (manifest) + renderer/invocation.
staticproperty (andconcurrency) onmacromodules. Today forge-sim treats every macro as a UI Kit / Custom UI surface with aresource+render; a static macro is function/endpoint-backed with no resource, so UI module detection needs to recognize the shape instead of flagging it as malformed.forge_ui_render/ in-process macro rendering assumes a ForgeDoc tree. Static macros need a distinct path: build an array of macro-arg payloads (batched up toconcurrency), call the function or remote endpoint, and surface the returned ADF / Storage Format nodes. Parity means rejecting a non-array return and honoring the batch shape.forge-sim devrenders macros in an iframe; a static macro should render its ADF inline (or at least expose the raw nodes) so the local loop matches Confluence.Nothing here alters existing documented macro behavior; it is an additive module shape. Confirm the exact
static/concurrencyschema and the argument/return payload against the static macros docs before implementing.