Support to add Diagrams on Atlassian Platform - Confluence

[everywhereautomation777]

Confluence integration — embed OpenFlowKit diagrams as a live macro

Suggested GitHub Discussion category: Ideas

The idea

A way to surface OpenFlowKit diagrams inside Atlassian Confluence pages — ideally a Marketplace (Forge) app that renders a diagram as an embedded macro, with a lighter export-and-embed path as a fallback.

Why

I work in an enterprise AI/automation Centre of Excellence where Confluence is the system of record for architecture documentation. We maintain a lot of system-design and flow content, and right now there's a gap between authoring a diagram and living with it in the docs.

Today the realistic OpenFlowKit → Confluence path is export a PNG/SVG/MP4 and attach it to a page. That works, but the diagram immediately goes stale — any edit means re-export and re-upload, and the diagram-as-code source of truth lives outside the page. For teams doing architecture reviews and onboarding docs in Confluence, a static image is exactly the thing OpenFlowKit's animated/live model is trying to move past.

draw.io and Mermaid both have strong Confluence Marketplace presence, and it's a meaningful reason teams pick them despite OpenFlowKit being a nicer engine. Closing this gap would make OpenFlowKit viable as the primary diagramming tool in Confluence-centric orgs, not just a side tool people export from.

What it could look like

A few options, roughly in order of effort:

1. Forge macro app — embed a diagram by reference (OpenFlow DSL/JSON or a shared link), rendered live in the page. Edits propagate without re-upload. This is the dream but the heaviest lift.
2. Smart export + embed helper — a one-click "Copy for Confluence" that produces a clean SVG plus the DSL/JSON in a way that's easy to round-trip back into the editor. Lower effort, keeps OpenFlowKit's no-backend, local-first model intact.
3. DSL-as-source-of-truth pattern — store the OpenFlow DSL in the Confluence page (or alongside it) and document a clean re-import workflow, so the page itself carries the editable source even without a macro.

Given OpenFlowKit is a pure static SPA with zero server-side storage, I realize option 1 conflicts somewhat with the local-first, no-backend philosophy — a Forge app implies a hosted/Forge runtime. So option 2 might actually be the more on-brand answer, and I'd be curious how the maintainers think about that tradeoff.

Open questions for the community

• Is a Marketplace app on the roadmap at all, or out of scope by design?
• Would an export path optimized for Confluence (vs. the existing Figma export) be enough for most people here?
• Anyone else hitting this in a Confluence-heavy org — what's your current workaround?

Happy to share more detail on the enterprise documentation use case if it's useful for scoping.