RFC-84 Cross-product apps

[JuliaDaehne]

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines : keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Summary of Project:

The cross-product project aims to enable developers to build and distribute Forge apps that work across multiple products. This post explains our approach to tackling the problem including some high-level technical designs. We’re looking for feedback to make sure we build the best possible solution. Please note that as we continue to evolve the below outlines principles can change over time.

• Publish: Feb 11 2025
• Discuss: Feb 25 2025
• Resolve: Mar 11 2025

Problem

Currently, Forge apps can be installed across various products, but they cannot be marketed as a single cross-product app on the Atlassian Marketplace.

Developers have the option to distribute their apps directly; however, this approach limits their app’s visibility and potential sales opportunities.

For those interested in selling cross-product apps on the Marketplace, a workaround involves creating a “helper app.” This design allows the ‘helper app’ to proxy API calls to a secondary product on behalf of the “primary” app. Unfortunately, this method introduces complications, such as the necessity to eliminate egress for cross-product apps utilizing the helper app workaround for Runs on Atlassian.

Through this RFC, we propose a more flexible installation architecture that enables a single app to be installed in multiple locations simultaneously. This solution would allow the app to utilize APIs and extension points from multiple Atlassian products and platform components, providing a genuine cross-product app experience for both, customers and partners.

Who are we solving for?

Customers

Admins need the ability to explore applications that deliver enhanced value across various Atlassian products and their own data. This capability is increasingly vital as the evolving Atlassian System of Work will provide more options over time to connect Atlassian portfolio as one powerful, interconnected system that serves every team within an organization. Apps will play an important role to facilitate these connections and customers will expect to find such apps on the Marketplace.

Partners

Creating applications that facilitate communication across products or platform components is a significant requirement for partners. This capability enhances the overall user experience for customers and thus opens up new revenue opportunities for partners.

For instance, Rovo’s user experience is integrated into the broader Atlassian platform, rather than being limited to a single product. With cross-product applications, users can utilize a custom Rovo action in Confluence to retrieve data from Jira seamlessly.

Another compelling example is the Forge platform extension. Applications that span multiple platform components will unlock an exciting realm of cross-product functionalities for customers. Imagine a Forge app that connects visually appealing Atlassian Home dashboards with content from Jira and Confluence. Additionally, integrating Teamwork Graph into cross-product apps could lead to more powerful experiences, leveraging AI, search, and automation across Atlassian products.

Proposed Solution

General

Every app installation retains a primary installation context, as it has today. Secondary installations context(s) determine which additional product(s) the app can extend and communicate with.

Installations may have zero or more secondary installation contexts. Importantly, these share the same installation ID as the primary context.

To start with, we will allow developers to build and deploy apps that operate across multiple products within the same site with a single installation. For our planned EAP milestone the installation management will be done entirely via the CLI.

Only site based products such as Confluence, Jira, Compass (possibly Teamwork Graph) are in scope.

Basic principles

• Cross-product applications will exclusively be accessible to Forge apps; they will not function with harmonized applications that utilize Connect modules.
• Once installed, the primary installation context cannot be altered unless there are no existing installations of the app in the specified environment.
• The primary context governs the processes of installation, upgrade, and uninstallation. Consequently, when a primary context is uninstalled, all associated secondary contexts will also be removed.
• Additionally, the Data Residency status of a cross-product app is contingent upon the primary installation context.

Licensing

The billing structure will be tied to the primary installation context, meaning that the license will depend on the number of users within the main product where the app is installed in.

As we advance in our efforts to provide more flexible licensing options, we will consider the possibility of implementing various licensing models into the cross-product app context. For example, a cross-product app with the primary Jira installation context could be ‘licensed user’ billed and have a secondary context in Confluence that is ‘usage’ billed.

However, different licensing options for components of a cross-product app will not be included in the initial phase of cross-product app development.

Storage

Data Residency

Currently, apps are aligned with the product and pinned to the product location selected by the Admin in admin.atlassian.com.

For cross-product app data stored in Forge Storage, secondary context installations will adhere to the primary context installation. For example, if the primary product is pinned to Australia and the secondary product is pinned to the EU, all cross-product app data will be stored in Australia.

When primary and secondary products are pinned to different regions, the latency of storage for the secondary installations will be unaffected. However, there is an expected latency of around 100ms for every product API call against a pinned secodanry context in a different region.

We will ensure that Admins are well-informed about this when they modify their product’s data residency region.

Product delete and soft delete

Each cross-product app context shares a single installationId, which governs the soft delete and restore processes.

The single installationID is related to one shared storage for primary and secondary contexts. Therefore, removing a secondary product will not remove app data relating to the secondary context.

App data will only undergo soft deletion or restoration if the primary product context is deleted or restored.

Compute

Admins have the flexibility to install and uninstall products at any time, which may affect your cross-product app. To assist you, we can provide information regarding the product context in which the app is installed during runtime. This could be achieved by passing the context information through the app context API.

Webtriggers

All product contexts refer to a single installation ID for cross-product applications. We do not anticipate any changes to the current process for setting up web triggers. To obtain the web trigger URL for a specific site and product, simply copy the installation ID and execute the following command to generate the web trigger URL.

1 forge webtrigger

App Management

Admins will have the capability to view and manage cross-product applications through the Connected App screen at admin.atlassian.com. Both, primary and secondary installation contexts will be displayed, allowing Admins to manage them effectively. Although we do not have any designs to share at this moment, Admins will be able to view, upgrade, and uninstall their cross-product apps within the Connected Apps section.

Uninstalling secondary context installations will be permitted at any time, and new contexts can be added as they become available. Additionally, all products where the app is installed will be updated when an app update is executed.

App discoverability

Customers will eventually have the ability to discover and install (or request) cross-product apps via the Atlassian Marketplace.

Currently, we are not suggesting a specific category for cross-product apps within the Marketplace. Instead, these applications can be found through the primary product, where additional cross-product benefits will be highlighted.

Proposed Milestones for cross-product apps

Milestone 1: Developer EAP

In this milestone, we will establish the groundwork for cross-product app development. Developers will have the capability to create and install cross-product apps on products within a single site, such as Jira, JSM, Compass, and Confluence (potentially including Teamwork Graph).

Forge Create Mock Up

We will look at introducing new templates to create cross-product app experiences via forge create.

Manifest

The manifest for a XPA installation could look like this:

Forge Install Mock Up

The primary installation context is defined in the manifest, establishing its configuration at the time of deployment. Consequently, during the installation phase, the primary product will be displayed by default in the CLI wizard or when arguments are supplied to your code.

Once the primary installation is done the secondary installation context(s) can be selected and installed.

Milestone 2: Preview

In this milestone, we will introduce the capability to distribute cross-product apps via a direct distribution link and monitor apps in the Developer Console. Users will have the option to filter installations and logs by product.

For Admins cross-product apps will be accessible through admin.atlassian.com, where they can be viewed and managed, along with their primary and secondary installation contexts.

Milestone 3: GA

In this milestone, apps will become discoverable on the Marketplace and can be installed by Admins or requested by users.

Milestone 4: Post GA

Following the GA release, we will look into expanding cross-product apps to non-site-based products like Bitbucket.

Actions

We welcome your thoughts on this RFC and, in particular, would greatly appreciate your feedback on the following questions:

1. How would you like Admins to discover your cross-product apps on Marketplace?
2. How would you like to set the pricing for your cross-product app?
3. Are there specific cross-product app templates that you would like to see available?
4. Are you concerned about above mentioned latency issues arising from primary and secondary contexts being pinned to different regions?
5. Do you want to know at runtime what product workspaces your app has been installed into - such as when secondary installation contexts are added or removed?
6. Would you consider to migrate existing cross-product apps (with separate installation IDs) to the new cross-product app architecture in the future? If so, what support from Atlassian would you expect for such transitioning effort?

Our objective is to launch an Early Access Program (EAP) by April 2025. If you would like to participate in the EAP, please sign up here.

We are looking forward to your feedback!

[BenRomberg]

@JuliaDaehne thanks for the RFC - sounds exciting!

Are you also considering to allow a single app to communicate between different e.g. Jira instances? For example, our biggest app Deep Clone for Jira allows to clone issues and projects between different Jira instances/sites, and we would very much like to be able to achieve “Runs on Atlassian” without having to reduce our app’s functionality.

We also plan to introduce cross-instance communication for other apps of ours, since it is a request we hear a lot from enterprise customers who often utilize multiple sites for the same product.

[tobitheo]

Hi @JuliaDaehne!

We currently have a Jira app in the marketplace that has to use weird workarounds (External auth to a 3LO app with a proxy in the middle of the auth process exchanging the client IDs because external auth doesn’t do Atlassian client IDs natively) to communicate with Confluence, so this would benefit us directly.

@JuliaDaehne

Only site based products such as Confluence, Jira, Compass (possibly Teamwork Graph) are in scope.

Just to make sure I understand this correctly, this means no Jira app with additional product Bitbucket for the foreseeable future, right?

@JuliaDaehne

Uninstalling secondary context installations will be permitted at any time, and new contexts can be added as they become available. Additionally, all products where the app is installed will be updated when an app update is executed.

I would appreciate it if admins that are installing the app (from the marketplace or direct distribution) could get the chance to choose secondary contexts to the be added both at primary app install time and later.

• At primary context install time (i.e. when they install the app from the marketplace) makes sense to minimize admin intervention later. However I could see this being scary or hard to understand for admins. To help explain it, I would appreciate it if we could add an explanation for this to the manifest as I don’t anticipate that it will always be clear why a Jira app might need to access Confluence for example. I hear optional egress permissions might be coming to Runs on Atlassian at some point, I could see the DX and UX for adding explanations to be similar between those functions.
• I would also appreciate there were a functionality provided via the @forge/bridge package (for example) to open the native UI to request the admin install the secondary contexts at a later time when it makes sense from a UX flow inside the app.
  • For example a user wants to initiate a Confluence export of data inside a Jira app but the Confluence secondary install context is not installed, at that point it makes sense to ask the admin to install the Confluence portions of the app.
  • There should also be a way for non-admins to request this action from admins

More questions:

1. How does this impact existing cross-product apps that are unlisted on the marketplace? We have one that we use internally, but there is probably some vendor out there who has some out using install links.
2. I suppose any UI modules in the other products would then appear in the other product when the secondary install context is added, right? Or would this only encompass access to the secondary install context product’s API?

As to your questions for us:

1 through 3: I will forward this internally to our marketing team.

4: For the purpose of our app, not really. The actions our Jira app takes in Confluence are backgroundable. I think as long as Compute for the function calls originating from the secondary product are co-located with the storage, that is just something, someone who has such an… unusual constellation is going to have to live with. I could see this being differentiated in the future, but for now this is absolutely acceptable
5: Yes, this would be necessary so we could show appropriate UI like error messages or hints, greyed out options or request installation of secondary contexts as detailed earlier in my post
6: Yes, but since it’s only a 3LO app we’d be migrating from in our case, I don’t think we’d need any assistance. This might look different for other vendors though.

I’m not sure if we can justify participating in the EAP from a time investment perspective at the moment though, sorry.

Cheers,
Tobi from resolution

[tobias.viehweger]

@JuliaDaehne

Cross-product applications will exclusively be accessible to Forge apps; they will not function with harmonized applications that utilize Connect modules.

Hi Julia,

cross-product sounds great. I have a question regarding this sentence. This means, until we have moved all our Connect-on-Forge modules from the yml file to native custom UI modules, we would not be able to add a compass module, is that correct?

Thanks
Tobias

[erikmidtun]

As a marketplace vendor for a Cross-product Forge native app, we have been wanting this for a while! Currently we offer a Jira app -Automated User Cleanup & Deactivation for Jira- which supports both Jira Software and Jira Service Management. We also have a Confluence app -Automated User Cleanup & Deactivation for Confluence - which is limited to Confluence. They share the same codebase, but we have product specific implementations of certain parts. While both apps share the same codebase, certian components are implemented seperatly for each product.

We currently do NOT have any communications going between them. The main reason for this is that we offer Data-residency.

While we welcome this addition, we have a few concerns:

• Based on our understanding of this RFC, if an app has Jira registered as its primaryProduct, customers who only use Confluence would be unable to install it.
  • This will require us to continue offering two separate apps. Ideally, we would prefer to offer a single app on the marketplace, as managing multiple apps increase both development time and support effort.
  • A way to mitigate it on our side would be make both our apps into cross-product apps. Letting our apps use new capabilities, but only require one of the apps to be installed for our customers.
• We will be hesitant transition our apps into cross-product apps under the proposed licensing model due to potential license abuse.
  • For example, if a customer has 10 Jira users but 1,000 Confluence users. Our app would effectively be free for those additional confluence users. Since Forge is moving to a usage-based paid pricing model next year, this scenario could result in financial losses for us.
• How will this affect the existing Forge quotas? Will it be tided to the primaryProduct quotas similar to the licensing model ?
  • If this is the case, using the same example (10 Jira users and 1,000 Confluence users), our app might not be able to handle the increased load due to insufficient quotas.

Regarding some of your questions:

4. Are you concerned about above mentioned latency issues arising from primary and secondary contexts being pinned to different regions?

• We do not foresee this being an issue, as few (if any) customers operates cross multiple regions.

5. Do you want to know at runtime what product workspaces your app has been installed into - such as when secondary installation contexts are added or removed?

• Yes, this will be a necessary change for us to consider migrating to a cross-product app. Ideally, this information should be available in the AppContext, allowing us to query it programmatically as needed. We would also like it accessible in both the backend resolvers and on the frontend modules.
• We would also like new Forge lifecycle events for secondary installations and uninstalls, as these events would enable us to manage stored data more effectively and ensure compliance with privacy and data storage policies

6. Would you consider to migrate existing cross-product apps (with separate installation IDs) to the new cross-product app architecture in the future? If so, what support from Atlassian would you expect for such transitioning effort?

• A clear migration path would be crucial. Specifically, we need to understand how stored data would be impacted. For example, what happens if two apps have the same storage keys or entities?

[BorisBerenberg]

@JuliaDaehne

they will not function with harmonized applications that utilize Connect modules.

Does this mean Connect on Forge?

@JuliaDaehne

The billing structure will be tied to the primary installation context, meaning that the license will depend on the number of users within the main product where the app is installed in.

So if I want to buy an app, but I don’t want to pay a lot for it, the plan will be buy Compass for 10 seats, buy the app there, then distribute to the rest of the products in the site?

@JuliaDaehne

Once installed, the primary installation context cannot be altered unless there are no existing installations of the app in the specified environment.

What happens if Atlassian retires the parent app?

[remie]

@JuliaDaehne

The billing structure will be tied to the primary installation context, meaning that the license will depend on the number of users within the main product where the app is installed in.

This would be a no-go from our perspective. We are currently selling our Figma for Jira and Figma for Confluence as separate apps, even though they share a common code base and our customers would really benefit from cross-product integrations.

If we would only get paid for the Confluence instance, we would loose a significant income stream (~40%).

We would love to provide cross-product features, but not at this cost.

I would love to see this combined with the flexible monetisation options that the Marketplace team is currently working on.

[david.toussaint]

Hi @JuliaDaehne, thanks for sharing that sounds exciting!

@JuliaDaehne

Currently, we are not suggesting a specific category for cross-product apps within the Marketplace. Instead, these applications can be found through the primary product, where additional cross-product benefits will be highlighted.

Can you share what speaks against listing the app for all products on the Marketplace (i.e. not just primary)?

I do agree with previous posters about the risk and little control of license abuse in the proposed solution. Any insights in mechanisms to prevent that would be highly appreciated!

Thanks, David
Communardo

[danielwester]

YES PLEASE!!!

I totally understand that for folks that want to be able to offer the same solution in multiple apps - but we’d love this as we want to offer an extension into Confluence from the our main app. This would be awesome!

If we have the same app in both Jira and Confluence - I’d probably not go for this (I agree with folks about the risk in this area)

Our current goal is to offer integration to our main app and this seems to fit that.

When can we get it?

/Daniel

[JuliaDaehne]

Hi @BenRomberg unfortunately the use case you are describing would not be covered through cross-product apps as your primary product context needs to be different to your secondary product context. We will also start with a single site concept for cross-product apps

[JuliaDaehne]

Hi @tobitheo thanks for taking the time to provide such detailed feedback. I’m glad to hear this will be a welcomed feature for you.

We are currently focusing on the products mentioned in the RFC - Bitbucket will likely be a post GA deliverable.

I very much agree with you on the Admin installation experience: it should be clear to the Admin that more product contexts can be installed and what value they can bring from the Marketplace listing but also at time of installation. We could think of a default message that can be customised by the partner in the manifest.
The forge bridge idea is an interesting one as well - the only thing to keep in mind here is that the user seeing this msg pop up in the UI does not necessarily have the admin installation permission. In that case there needs to be indeed a link to the ‘app request’ feature.

To your questions on current cross-product apps you may have:

1. You can change your current cross-product app to the new architecture. For this to work the app that will become the new primary installation context should not have any existing installations. As an example: you can convert a non cross-product Jira app and then choose to add a new secondary Confluence or Compass context. There is no migration path for an existing app to be added as a secondary product context
2. I’m not quote sure what you mean. There is no change to how modules work. Would you mind re-phrasing this pls

Thanks for considering the EAP - I understand the time constrain

[JuliaDaehne]

Hi @tobias.viehweger yes unfortunately we cannot support any Connect modules for cross-product apps.

[JuliaDaehne]

@erikmidtun

if an app has Jira registered as its primaryProduct, customers who only use Confluence would be unable to install it.

That’s correct. Your proposed mitigation approach could work. When you say ‘use new capabilities’ I’m assuming you mean an additional secondary product context added? If so pls be aware that the secondary context will be pinned to the same region as the primary as mentioned in the RFC

[JuliaDaehne]

As some of you have expressed their concern around potential license abuse: this can only be addressed through more flexible licensing options we are currently working on. This could allow to price the primary and secondary product installations differently, for example bill for licensed users for primary and for usage for secondary installation context

[JuliaDaehne]

Looking forward to seeing you in the EAP @danielwester

[remie]

Right, so there are indeed plans to allow us to charge users for secondary products?

[Chris_at_DigitalRose]

Hi, As a vendor with apps in both Jira and Confluence we’re overall impressed with the idea of cross-product apps. As some vendors had mentioned the primary and secondary context makes it feel awkwardly still product specific. Either build a “Jira app with a side job in Confluence” or a Confluence app that can also work with Jira.

I’m sure the design team considered just making 'Atlassian Cloud" apps that had a compatibility flag for Jira, Confluence, Compass? Can I ask why that didn’t work? It would seem to simplify some of the marketplace admin items (e.g. the app shows up everywhere its compatible), and remove the complexity of primary vs secondary.

And as a few people mentioned, this current primary/secondary is going to prevent omni-directional installs (e.g. Jira first, or Confluence first). A true “Atlassian Cloud” app could be installed and enabled for any product first. But also gives the customer (and vendor) an opportunity for an easy upgrade sale.

And then billing would be done equivalently… assume you would just make the pricing tier configuration available for all “compatible” products. If they had 10 Jira users and 1000 confluence users the customer is charged for both sides.

Just a thought… thank you for reading.

Chris
Digital Rose

[tobitheo]

Thanks for the reply and consideration!

Let me clarify my question:

@tobitheo

I suppose any UI modules in the other products would then appear in the other product when the secondary install context is added, right? Or would this only encompass access to the secondary install context product’s API?

Let’s say I have an app where the primaryProduct is Jira with Confluence as a secondary install context. I declare a Confluence Page action module in the manifest. I suppose this would

• not be visible in Confluence if the app is installed only in Jira initially (i.e. without being installed in Confluence as the secondary context)?
• become visible in Confluence after it is installed in Confluence as the secondary installation context

Is that correct? Or does a secondary installation context only grant API access to the secondary install context (via requestConfluence in this example) and not allow for UI modules to be added via the app?

[sopel]

As a partner integrating with a 3rd party platform (AWS), we implemented our first Forge app based on the prominent cross-product vision at launch, only to learn the hard way that we cannot sell it on the Marketplace (other than that unexpected ‘detail’, installing one app into both Jira and Confluence actually worked as advertised) - we are obviously excited to finally see this vision getting some traction. Seeing the Teamwork Graph as another potential ‘product’ atop makes this even more compelling.

• More specifically, we currently have 2 (plus 1 in the works) cross-product app ‘families’ that will conceptually be available for all Forge enabled products, i.e. Jira, Confluence, Compass (and later Bitbucket - I appreciate the site vs. workspace complexity to be tackled post GA).

That being said, this (hopefully just initial) ‘helper’ or ‘companion’ app approach is not how ‘cross-product’ apps had been envisioned so far, which I’d classify more like ‘site-based’, i.e. we only ever expected to either install the identical app into multiple products (as with private apps today), or even better, install the app just once into an Atlassian site - in both scenarios the app would just automatically surface their cross-product capabilities, simply based on whatever (usually product specific) Forge modules we choose to implement in the shared code base.

Accordingly, all the concerns and questions raised in RFC-84 Cross-product apps - #5 by erikmidtun and RFC-84 Cross-product apps - #17 by Chris_at_DigitalRose affect us as well, so it likely doesn’t make sense to participate in the EAP based on this limited ‘cross-product helper app’ model (I realize it already solves for many other use cases, which is great!).

Regardless, here’s our current take on your questions:

1. How would you like Admins to discover your cross-product apps on Marketplace?

While the core capabilities of our cross-product apps overlap semantically, the specific features can still differ considerably (consider e.g. the same content displayed via Jira dashboard gadget vs. Confluence macro), so we’d absolutely prefer product-specific listings to get the value proposition across via tailored highlights etc. - the cross-product aspect really just needs to be an easily discoverable upselling annotation like ‘also works in x/y/z’.

2. How would you like to set the pricing for your cross-product app?

We definitely want to grant some form of discount for customers with multiple apps and, given we didn’t consider the ‘helper app’ limitation, have considered two models so far:

1. Either just sum the pricing for the independently purchasable product-specific listings and apply a discount percentage, i.e. similar to how app bundles are shaping up
2. Or determine the pricing by the most expensive license, i.e. get all others for free

3. Are there specific cross-product app templates that you would like to see available?

Not sure I understand what you are heading for, can you provide an example? Got it! I think one simple plus one comprehensive CLI template would be enough, with the latter showing advanced cross-product API/IX patterns via queues etc.

4. Are you concerned about above mentioned latency issues arising from primary and secondary contexts being pinned to different regions?

No, this is irrelevant for our AWS integrations (the cross-product interaction usually happens indirectly via our remote backend anyway).

5. Do you want to know at runtime what product workspaces your app has been installed into - such as when secondary installation contexts are added or removed?

Absolutely, as already outlined by others, this informs how we present and advertise the various cross-product experiences, i.e. it’s instrumental for great UX - besides, this would also allow for more flexible pricing/discount handling as per 2, e.g. we could unlock features in a cross-product app that isn’t licensed.

6. Would you consider to migrate existing cross-product apps (with separate installation IDs) to the new cross-product app architecture in the future? […]

Not yet - as outlined above, our semantically cross-product apps are not suited for this limited ‘helper app’ approach, so we are hoping you’ll evolve this into the full featured ‘cross-product app’ model already available for private apps down the road

[t-bundt]

@JuliaDaehne

6. Would you consider to migrate existing cross-product apps (with separate installation IDs) to the new cross-product app architecture in the future? If so, what support from Atlassian would you expect for such transitioning effort?

Yes, but will it be possible to migrate a macro from a Confluence helper app to the Jira main app?