Forge extensibility update: July 2021

Hi Forge community,

Earlier today, we shared a blog post updating each of you on the progress we have made in terms of extensibility of our Forge platform this year. In this thread, I’ll go into some more detail on what we have delivered over the last 12 months, what’s coming next, and answer any questions that you may have regarding Forge extensibility.

What has shipped this year?

Within the past 12 month’s Forge’s extensibility has increased by 122% – we’ve added 11 new Forge extension points to unlock more experiences that can be built for Jira and Confluence. With 20 Forge modules in total, more apps than ever can be built with Forge, including some that previously could only be built with Connect.

We’ve also published a new page in our Forge documentation, a list of Forge and Connect parallel extension points - which you can find here. As of today, over 55% of existing Connect apps use modules that already have an equivalent in Forge.

Since June 2020 we have shipped:




What’s important to note is that Forge and Connect modules are not mirrored exactly – in some cases, a single Forge module can do the work of two or more Connect modules. This means fewer, more powerful modules in Forge that are simpler to keep track of and maintain in your app.

What’s coming next?

In our extensibility update blog post, we share details on our process of calculating ‘effective coverage’, which we have used to highlight which existing Connect modules to build next on Forge. In short, by harnessing usage data provided by the 25,000+ developers and 1,000+ Marketplace Partners already using Connect, we are able to prioritise the Forge modules which provide the greatest value for both developers and users.

In our new Connect module equivalents page aforementioned, we also have added a section that we will continue to update with Forge modules that are added to our roadmap. Currently, we are considering Forge equivalents for 10 more of the most used Connect modules:

Cross Product

  • General Pages (Confluence) (Jira) - generalPages have no extra styling and by default a link to the page is displayed in the header ‘apps’ menu. Use these pages in order to display general content.
  • Post Install Page (Confluence) (Jira) - A “Get Started” button will link to this page from both the app’s entry in Manage Add-ons and from the dialog that the user is shown when they successfully install the app.
  • Configure Page (Confluence) (Jira) A “Configure” button will link to this page from the app’s entry in Manage Add-ons . Use this page to provide configuration of the app itself.



  • spaceToolsTabs - Enables apps to insert tabs into Confluence Space Tools area.

In addition to these new modules, we are also eagerly exploring how Forge can be used to extend other products in the Atlassian lineup, opening the door for builders and users to explore a whole new range of exciting opportunities.

We want to hear your thoughts!

We’d love to hear your feedback on these new modules that we are exploring next - whether they will be useful for your Forge use-case, or whether you think we have missed anything important to the progression of your Forge app. Based on this community insight, we do acknowledge that our roadmapped modules (and the order in which we deliver these) may alter slightly in the future.


Thanks for the update! We’d love to write Forge apps ourselves, however in our opinion, the coverage gap is still greater than is illustrated in the blog post.

For example, Connect apps use the webItems module quite often to hook into Jira’s menus and open dialogs or new pages. It even has its own Connect app, just to show where webItems (and webSections etc.) can be used.

If I understood correctly, in your statistic, it would only count as a single module, but I’m pretty sure it accounts for far more than 1/42 of module usages. So as long as you don’t have a replacement option within Forge, many Connect apps will still be blocked to migrate to Forge and many new app ideas will still be easier to implement with Connect.

IMHO you would get better feedback how far you are with Forge module coverage if you would adjust your coverage metric to measure module usages instead of just “number of modules”. Scan all Marketplace apps and count how often these modules are being used in their descriptors, and then count how many of those usages offer a replacement within Forge. My guess is that it will probably be significantly lower than the 50% coverage. In any case, you would have a more realistic assessment of module coverage related to Connect - even if it’s higher than “number of modules” coverage!

I hope this helps getting Forge closer to Connect as we’d really love to do more with Forge in the future. In any case, thanks a lot for the “high level” update :slight_smile: