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:


Hey @ben2, cheers for your feedback! In response to your concerns:

We 100% understand that webItems and webPanels are a large part of building on Connect, however the inconvenience surrounding the use of these locations (such as having to use a third-party app to locate them as you have mentioned) was one of the main reasons as to why we have decided to take a more simplified approach towards modules in Forge. In our module coverage analysis, we extrapolated all possible locations within webPanels and webItems and effectively treated each as its own module. Through doing this, we found that there was quite a long tail of locations that were being used by a small subset of apps, while the vast majority of usage was concentrated in 3 or 4 locations - these locations directly correlated with Jira issueGlances and issuePanels that we have today in Forge. These most popular Connect locations and their Forge equivalents are listed here on our docs. Out of curiosity, which Connect webPanel locations are blocking your development on Forge currently?

On our methodology for calculating module coverage - measuring module usages is what we placed most of our emphasis on, in order to stack rank priorities in a way that benefits both builders and users. To do this, we looked at Connect modules ranked by number of apps using them, as well as number of total invocations for each module over a 12 month period - this allowed us to prioritise extension points that were both highly used by Connect developers (using the # of apps stat as a proxy) and number of users (number of invocations as proxy). To your point about 50% of Connect apps currently able to be built on Forge, this was in reference to all apps (public and private) - those that are listed on Marketplace are only a subset of this, but more analysis would need to be done before I could say how this would affect that 50% number with confidence.

Hopefully that answers all of your concerns and thanks for taking the time to give your feedback! Happy to schedule a call to discuss any other requests that you may have with the Forge platform too :slight_smile:

1 Like

Hi @JordanKoukides,
Question - when you’re looking at the module usage etc - are there the other bits (icons, title capability, conditions etc) also taken into consideration?
The reason I’m asking is that those don’t seem to be taken into account (just having the projectPage without a way of checking the issue property existence for example, or how the number of instances of a module is limited in comparison to Connect).

It would be great if the connect module equivalent page (which is a great start) could have a level of feature parity within each module and have all of the above documented.

As a marketplace partner with customers I have to handle the documentation of the products, bug bounty programs etc. So a slight change in technical functionality(from your perspective) can and will have a really big impact on other parts of operating the app.


The Connect Module equivalencies page is a good start, but it only shows what is there already there or about to be implemented. It does not paint the whole picture.

Either in that page or in another one, simply add the connect modules, the equivalency and alternatives.

For example, in the case of Confluence, create a table with the existing Connect Module Types:

  • Admin Page
  • Blueprint
  • Content Byline Item
  • Content Property
  • Custom Content
  • Dialog
  • Dynamic Content Macro
  • Keyboard Shortcut
  • Page
  • Space Tools Tab
  • Static Content Macro
  • Web Item
  • Web Panel
  • Web Section
  • Webhook

Then add columns of equivalency, or alternative, and ETA.

Also, you can explain when Conditions and other properties are going to be available.

In the case of WebItem, include the available locations and the alternative or equivalency in Forge.

One of the main challenges we have if that we do not feel there is a good understanding of what does it takes to move a Connect App to Forge.

Until you publish a document like this for each Product, you are not going to gain the trust of all the Marketplace Partners about Forge’s roadmap.

Edit: Fixed typos.


Hi @JordanKoukides, thanks for your insights. I’ll see what I can do to share missing locations that are widely used in public connect apps (since I cannot access descriptors of private apps). From our own apps, we could probably migrate 2 of the 14 cloud apps we’re currently offering with the Forge extension points available today. The other 12 are missing at least one important module or something else like conditions as @danielwester has mentioned.


  • Analysing other Connect functionalities such as icons, conditions, etc are in future scope of the module coverage work that we shared in this post - definitely great to hear confirmation that this would be useful for you though.
  • As part of this, we are also looking to expand the module equivalents page as you suggested, I’ll make sure to pass this feedback on for future improvements


  • This is also great feedback, we’ll definitely look into adding all equivalents/alternatives to the page (including webItem locations too).
  • As for conditions, we do have Forge Display Conditions - I would be interested to hear what additional functionality would be required from these if they don’t currently satisfy your use-case.


  • Happy to have a chat about those 12 missing modules/functionalities - if it’s not something that you feel comfortable with sharing on here, feel free to book some time on my calendar for a Zoom call. Calendly - Jordan Koukides

Yes, there are some conditions, but as with many other components that are “already available in Forge”, they fall short to what Connect provides.

You guys have parsed all of the Connect app descriptors, so you should have a very good idea of the usage. If you guys think what it is provided now is sufficient, well, let’s have a conversation, as we do not believe it is.

Let’s take this as another example to illustrate the challenges we Marketplace Partners who have developer feature rich and successful apps in Connect are facing.

In Atlassian’s books and communications, Conditions are supported already in Forge.

However, the support of Conditions is limited:

  • First of all, there is a big gap between what is supported in Confluence and what is supported in JIRA. I.e. Confluence support is behind.
  • The link you provided only talks about Jira conditions. We know there is some support in confluence, but I couldn’t find the documentation, maybe you can share it.
  • Connect Conditions include not only conditions based on content properties but also on permissions, contextual information (e.g. has_, space_, user_, etc), and, specially important to us, app properties (e.g. entity_property_)

Again, if you guys provide a mapping from Connect to Forge (not the other way around) you will helping many Marketplace Partners at the same time to find what is going to be supported in Forge, when is it going to be supported, and what we’d need to handle differently.

@JordanKoukides, I appreciate your interest in learning more about the Marketplace Vendor needs. We are already in touch with the Forge team in Comalatech’s specific needs, and we are getting some traction.

What I am trying to do hear is to give you a broader perspective, trying to cover not only our needs but what I believe is common across other Marketplace Vendors.


Hey @roberto, I appreciate you raising these concerns about Confluence conditions in Forge. I’m looping in @ElaineH who is the Product Manager responsible for Confluence Cloud - she will be able to go into more detail on the current and roadmapped capabilities for Confluence Forge apps, particularly those that use Conditions.

If you guys provide a mapping from Connect to Forge (not the other way around) you will helping many Marketplace Partners at the same time to find what is going to be supported in Forge, when is it going to be supported, and what we’d need to handle differently.

This is a great callout (and one I completely agree with). Please trust that we are working to make this happen - our new document mapping Forge and Connect modules is just the beginning, we are planning to expand this further to help developers who are transitioning from Connect to Forge.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.