Seeking Advice from Atlassian Developer Community on Jira Connect vs. Forge for Better User Experience

Dear Atlassian Developer Community,

I am writing to seek your expert advice on an issue I am currently facing with my Forge app development. Specifically, I am experiencing challenges in the user experience (UX) phase, as I am finding it difficult to exercise total design freedom, such as modifying or deleting the title frame.

In light of these challenges, I am considering using Jira Connect instead of Forge. However, I would like to solicit the opinions and insights of the Atlassian Developer Community to make an informed decision that will result in a better user experience for my app’s users.

Therefore, I would appreciate any advice, recommendations, or best practices that you could share regarding the use of Jira Connect versus Forge in app development, particularly with regards to UX.

Thank you in advance for your time and expertise.


1 Like


Have you tried both Forge UI Kit and Forge Custom UI?

@SarraMEHREZ Accepted Value Costing dev team went through a similar evaluation. We had more than just UI/UX considerations because we are integrating an existing databased product. Forge was a non-starter for us for that reason. Our conclusions re: Forge were 1) it extends Atlassian’s look-and-feel and 2) it is limited to routine functionality. There are two more approaches open to you: Connect and third-party-style (with 3LO). IMO Connect is your only practical choice. It will give you total UI design freedom; we are using our own CSS but we try to make it clean, simple, elegant, and not in conflict with Atlassian. Be aware that the downside to using Connect is significant. Unless your app descriptor applies ONLY within your enterprise (and therefore you can use an authentication token and “none” for security) you will be faced with a profoundly challenging OAuth/jwt hurdle, not to mention multiple framework possibilities for REST API invocation.


If you are developing a paid commercial app that you wish to submit to the Atlassian Marketplace, please also note that

A) Forge does not yet support data residency. All data is processed & stored in the US, which is a potential red flag for anyone who has customers that are concerned with GDPR, ePrivacy Directive and Trans-Atlantic Data Privacy Framework

B) Forge comes with a zero warranty or liability policy (see sections 14 and 15 of If Atlassian fucks up and your customers loose their data, you will be liable and will not be able to put any responsibility with Atlassian, even though you are not supposed to do any off-site data retention and are pushed to store End-User Data with Atlassian.

Regardless of any technical limitations, I would stay away from Forge as far as you can if you are planning on any serious commercial activities on the Atlassian Marketplace.


Regarding UX design freedom, it is true that Forge has some limitations on modifying or deleting certain UI elements, including the title frame. If you’re looking for more control over the UX design of your app, Jira Connect might be a better choice for you. With Jira Connect, you have more flexibility and control over the app’s UI, allowing you to customize the UX design to meet the specific needs of your users. You’re having UX issues with your Forge app and are considering switching to Jira Connect, you can also check out more on Forge vs. Jira Connect.


Can I use both Connect Jira and Forge Jira in the same app ?

There is no point to doing that.

Actually, there is, and yes you can.

The point of doing that is twofold:

  1. to migrate existing connect apps to Forge, as described here:

  2. because Forge does not, and will not, support al use cases with regard to app specific resources. You may find yourself in need of services that Forge will simply not offer (like Redis, ElasticSearch, or more exotic AWS services). More complex apps will need those resources, and can use Connect on Forge to support data egress for these specific services whilst still benefiting from the Forge-specific infrastructure like Forge Storage API.

However, it is important to note that Connect on Forge is currently still in a very experimental state and not production ready (neither is Forge itself, BTW, but that is a different topic).


To gain a better understanding of how to integrate Forge and Connect together, could you please provide more details on how to use Connect on Forge for migrating existing Connect apps as well as supporting app-specific resources that Forge may not offer?

Additionally, could you elaborate on how Connect on Forge can support data egress for these specific services while still leveraging Forge’s infrastructure?

Moreover, as I would like to use Connect for the UI design of my application and benefit from the infrastructure provided by Forge, could you please provide further information on how this approach can be implemented effectively?

Lastly, could you clarify the current state of Connect on Forge and whether it is suitable for production use?

Thank you in advance,

1 Like

@HeyJoe and @jhazelwood are probably best suited to answer this question.

As for the other questions: I have no experience building any Forge app, including Connect on Forge, so I’m afraid I won’t be able to help out here, but perhaps there are others on this forum that might provide some insights. It seems like this is the more appropriate thread to ask that question given that @aron.gombas already mentioned there that they have experience with building a Connect on Forge app


Thank you for your response, I will explore the thread mentioned by @aron.gombas to see if I can gain additional insights. Thanks again for your help!

1 Like

Hi, all!

…can use Connect on Forge to support data egress…

Data egress from Forge to your remote app server is possible, but you’ll need to handle auth yourself (for now, we’re working on handling it for you in Forge).

could you please provide more details on how to use Connect on Forge for migrating existing Connect apps

I’ll avoid rehashing but I’m happy to answer any specific questions you still have after reading that!

how Connect on Forge can support data egress

Connect-on-Forge means a Forge app with a Connect app server and Connect modules. The connect app server can retrieve data via REST API calls authenticated with Connect JWT auth. Connect webhooks can be registered that send webhooks & data direct to the app server. Connect iframes can also egress data (and some specific bits of data and identifiers can be included in the iframe url - the details depend on what modules you are using.

use Connect for the UI design of my application and benefit from the infrastructure provided by Forge

The Connect front end can not easily talk to the Forge back end except potentially via web triggers. If what you want is full control over your UI look and feel via js HTML and CSS, backed by Forge infra, what you want is Forge Custom UI.

Lastly, could you clarify the current state of Connect on Forge and whether it is suitable for production use?

It is available to use but currently has a number of limitations that make it unsuitable for most apps.


Yes, you can use both in the same app. However, it may require more complex coding and development efforts as the two platforms have different APIs and may not always be compatible. Additionally, it’s important to carefully consider whether using both platforms in the same app is necessary for your specific use case, as it may increase the complexity and maintenance costs of your app.

Hi there,

Thank you so much for your detailed response, it’s really helpful. I appreciate you taking the time to explain how Connect on Forge works and its current limitations. I’m actually using Forge Custom UI to build my app, so that’s good to know. If I have any specific questions after reading through the documentation, I’ll be sure to reach out. Thanks again for your help!

1 Like