Tell me what you need in Forge

Hi folks, I’m looking to talk with at least 3 of you about your thoughts on Forge. If you have looked at Forge and taken it for a spin I’d love to understand where you stand on Forge today. Things I’m interested in discussing with you What do you like about Forge, when was the last time you used Forge, what would be a blocker for you in using Forge (technical, marketplace or business blockers as some examples).

If you have 30 minutes DM me with your interest and we can figure out a time to meet in the next week. If you don’t have time to meet and still want to provide feedback. Please send over your thoughts to me in DM.


Not sure if you are still looking for feedback but Blueprint support in Forge sounds is super important. Trying to develop a simple multi-page Blueprint app but since the blueprint_page_created callback doesn’t work in Cloud I’m looking at Forget but it doesn’t seem to have a Blueprint module yet.


I’m actually curious on how Atlassian is going to position Forge? Will Forge apps be available in the marketplace and if so, does Atlassian allow free apps? Or will Forge be more like the Confluence user macros?

At the moment Forge feels kind of limited, but this has also to do with my limited understanding of modern web development (react syntax :smiley: )

I would also like to see a Board action template, besides the Issue action templates.

Thanks in advance!

Hey Rick—I can answer two of those:

  • Forge apps will be available on the Marketplace (no date yet), and the Marketplace allows free apps.
  • We have a UI solution where you’ll be able to write arbitrary HTML/CSS/JS in the works, which will be releasing very soon. Watch this space!

Should we consider Forge as a future replacement for Connect? Or it can be considered as a frontend tool with a backend with restrictions (e.g. 10 seconds for function execution)?
Thanks in advance!

Hey Anton,

That’s a really complicated question. I think Joe puts it best in his blog post on this topic, which is that Forge and Connect currently co-exist, but will be combined into a unified platform in the future.

We’ll be announcing more details on this topic at Developer Day—make sure you tune in!

After giving Forge a extensive test drive I can say that the developer experience over P2 and Connect has increased. However one key capability that would make it outstanding is step debugging (e.g via Chrome de tools). If you would like more input you can also DM me.

All the best

Hey @lennardberger—Chrome debugging is not officially supported, but we’d like to find a solution to help our developers accomplish the same thing. We have a ticket for it at FRGE-29.

1 Like

Hey @huw this is really good news. Indeed, the -d option is quite hidden, I did not find it (or think of it). It would be amazing if the source tree was loaded into sources right away instead of using debugger; but I am not sure if that is even possible.

Hey, some form of dialogs and flags would be important. Dialogs/Modals should support custom UI.


Hey @dennis.fischer,

We’re currently working on Custom UI modal dialogs. Could you describe for us your use case for dialogs and flags and other things you need from Forge?

It will help us appropriately prioritise and make sure we implement these features in a way that achieves your required use case!

Hey @kchan,

I do not have any expectations how the respective modules are implemented. They could be part of something like @forge/bridge, after all, flags, modals/dialogs have to be displayed from the context of the top window.

Flags: A forge app should be able to create flags as displayed at As a user of flags I want to provide a title, a message, the type of flag and if it automatically dismisses.

Ideally, we can create new windows from the context of the top window object, i.e., we can have “full screen”(or very large in width and height modals/dialogs) iframes which can contain Custom UI. Possibly, this just loads another module which contains another custom UI created by e.g. create-react-app.

At a minimum, I would expect dialogs which allow user interaction as shown at, such that I can display warning, confirmation, danger dialogs.

Use cases:
Flags: We have apps that show flags after certain actions, for example, after a user saves their changes.

Dialogs: We have apps that show a dialog before a user proceeds with “dangerous” actions, e.g., getting the system/app/component into a state which will require restoring from backup. Another app uses dialogs to query for additional details and asks the user for input by showing e.g. a userpicker.

Surely some components of our apps can and will be redesigned to not rely on flags and dialogs, given future Forge limitations. However, I can safely assume that this is not possible for all components that our current Server/DC only apps use. A result would still be achievable without flags and dialogs, but the user experience will be decreased.

I have gathered a few more “blockers” or at least questions w.r.t. current Forge design:

  • The iframe contains attributes to define a sandbox="allow-forms allow-scripts allow-same-origin". As such, actions like navigation on the top frame are currently not possible. If my app shows a link to e.g. a Confluence page, then the page change would occur within the iframe, instead of the top level window.

  • Server/DC and Cloud in the top level window provide context parameters, e.g., AJS.Meta which is not available in the Forge iframe when using Custom UI. The backend receives information when called via @forge/bridge. How can I choose the correct language for I18n in a custom UI? How can I efficiently query for additional variables that define the context of the page, user, etc.?

  • Given the currently available Forge features, my ideal app creation workflow would look like this in the future:

    • Create a frontend-module with create-react-app or similar. Reuse available components from Atlaskit. Share the frontend-modules between Cloud and Server/DC app.
    • Define a service which allows to choose between Forge or Server/DC backend for all frontend to backend communication. Inject the correct service based on DI (e.g. Inversifyjs).
    • Define separate backends for Forge and for Server/DC.
    • Use the available integrations to show the created frontend-modules to the user (Forge —> Custom UI, Server/DC —> reuse the idea of using an iframe as we see it today in Forge).
    • Provide a bridge for Server/DC which allows iframe <—> iframe, and iframe —> backend communication, similar to what @forge/bridge provides.
    • Ship the same Cloud and Server/DC app to customers as I’m able to reuse all of my frontend code and waste less time in fixing Server/DC or Cloud specific shenanigans.