Another migration post rather than a launch — but this one’s for an app that’s less of a household name, so a quick intro first.
Confluence’s built-in Jira card shows a fixed set of fields in a fixed-size block — no control over what’s shown or how compact it is. Smart Jira Issue macros let you pick exactly which fields to display (compact inline strip or a boxed summary), and also cover something the built-in card doesn’t do at all: listing an issue’s children or a saved filter’s results in a table, with one-click status filters readers can use right on the page.
What changed: it’s been running on Atlassian Connect since it first shipped — its own Node server, its own database. All three macros are now rebuilt on Atlassian Forge, so the app qualifies for the Runs on Atlassian designation — no external server, and Jira data (fields, descriptions, filter results) never leaves Atlassian’s infrastructure. Every request is scoped asUser(), so there’s no app-level credential with broad access to the Jira instance either.
Existing macros, fields, and licenses carried over automatically with the migration — nothing to fix on pages that already have the macro on them.
This is a paid Forge app — disclosure, I’m the developer.
Curious whether “Runs on Atlassian” / no-external-server is something your security review actually checks for macro-level apps like this, or whether it mostly matters for apps handling bigger categories of data (reporting, automation). Would help me calibrate how much to lead with it going forward.
Smart Jira Issue for Confluence
