@remie we are actively looking into extending the new licensing options to cross-product apps. The feedback in this RFC will help us with these discussions and planning
1 Like
@Chris_at_DigitalRose I appreciate the call out and agree with your statement that the chosen cross-product app architecture is a product specific one.
The reason we chose this direction is that it will allow our partners to start building cross-product app quickly.
It does not mean are not locking ourselves into this setup. Our future milestones are very much driven with the Atlassian System of Work in mind and how we are looking at app discovery, installation and connecting customer and Atlassian data in the future.
1 Like
@tobitheo thanks for clarifying.
If you wanted your Confluence app to access Jira product APIs, you can make it a cross-product app. But you can also have Jira UI modules appear in Jira if installed as the secondary context.
Hi @david.toussaint one thing that comes to mind: for this first iteration of cross-product apps you can’t install a secondary product context without the related primary. So if a customer discovers a cross-product app through its secondary context listing it will become a tricky installation experience: we would have to point the user back to the primary context listing and ask for this to be installed first.
@t-bundt you could add Confluence modules and code and then deploy the app with primary product Jira and relevant manifest changes from Confluence. Before you do this make sure there aren’t any installations of the Jira app. Alternatively you create a new app as the cross-product app
@JuliaDaehne
So:
Once installed, the primary installation context cannot be altered unless there are no existing installations of the app in the specified environment.
means you can’t even go from currently no primary installation context to setting a first primary installation context, unless the app has no installation.
So most existing marketplace apps aren’t eligible, since they typically have installations.
Maybe you should make this more clear in the RFC description.
Are there any plans to ever get rid of this limitation?
Thank you the response @JuliaDaehne.
Candidly, as a vendor with existing Jira and Confluence apps that today can be installed in either Jira or Confluence, this RFC with the primary/secondary complexity is not a compelling cross-product offering (for us).
Maybe existing vendors with apps for multiple products are not the target audience; for us, today, this RFC is only half-way to being usable.
Sincerely,
Chris
Digital Rose
1 Like
I think this RFC could do with a stronger explanation of what advantages this would have for customers. I’m not convinced that anyone using the Atlassian products cares whether a single app was installed for their products, or an app for each product was installed. So long as they get the same functionality.
Is there a deeper reason that Atlassian apps need to be cross product. Perhaps for some other upcoming Atlassian chage?
2 Likes
@t-bundt yes that’s a restriction we have been discussing for a while now so it’s good to see your input here.
The concern was the Admin experience when an installed app becomes a cross-product app: a site admin could just add more product contexts without any review or approval by org admin. This site admin installation right is already a red flag for a lot of enterprise customers who are keen to security review and approve app installation or access to their data.
On the other hand I understand that not allowing installed apps to become cross-product app very restrictive for partners to adopt the new concept.
We could evaluate allowing the cross-product app adoption for installed apps in EAP and Preview milestones to learn more about possible admin concerns
@MattDoar with this first cross-product app iteration we want to overcome the limitations of the current workarounds in place.
For instance: with the helper app setup for cross-product apps it requires two apps to be manually installed by an admin who may not be the same as the admin managing it. This could lead to an unintentional app uninstall of one of the apps. Or one app being blocked by a data security policy.
The workaround also requires egress declarations for the two apps to communicate. This changes the security posture of the app from a customer’s perspective and makes the apps ineligible for Runs on Atlassian
Hi @JuliaDaehne ,
Thanks for this RFC – this would be a fantastic addition to the ecosystem!
Very much, that would be fantastic.
It would be nice to be able to set it either by the primary product or for each individual product. In our case, the primary product would be Compass, so being able to set any price at all would be welcome.
No, we do not tend to use the templates much.
Yes and no. Latency is of course a nuisance and might sometimes become annoying, but being able to build cross-product apps is well worth some latency.
Yes, that would terrific. At the very least, it would be allow us to inform users in the UI which cross-product features (if any) are available.
No, we do not have any of those in the marketplace. But we would very much like to re-anable existing cross-product features in one of our apps.
Additionally, I was wondering how you expect cross-product apps to communicate with each other. For example, we would love for something like cross-product storage to become available (see FRGE-918)
Again, this would be a really welcome and exciting addition to the ecosystem.
1 Like
Hi @JuliaDaehne
I am very happy to hear cross-product apps are on the horizon. We were actually just in the process of adding cross-product features to a few of our apps (eg save a sprint review presentation generated from Jira tickets to a Confluence page), and were looking at implementing the non-ideal helper-app workaround, so the implementation presented in this RFC is exactly what we were looking for 
Allowing an app to perform cross-product API calls adds a lot of potential functionality to our apps.
As for your questions:
- For our uses cases it definitely makes sense for the app to only show up when searching for the primary product, but it would be very useful for admins to see that the app can also be installed in additional contexts, with a note as to what functionality that enables.
- For our planned use cases of simply calling cross-product APIs, continuing with current billing is fine. However, as soon as new UI elements and functionality is implemented in the secondary contexts, then the user tier in the secondary install contexts must be taken into account as well, otherwise it doesn’t make sense financially for us.
- No specific wishes
- This would not be an issue for us, as I expect calling cross-product APIs will already be a lot faster than current workarounds. I also hope the customer would understand the additional latency if they pin their products in this way.
- Yes, this would be very important, so that we can let the user know which functionality is available, and what steps to follow to enable the cross-product functionality.
- With this RFC we have paused our development of cross-product features (we were going to create additional helper apps to enable cross-product communication), and are now eagerly anticipating the release of cross-product apps. I’ve signed up for the EAP, would love to see if this cross-product app solution works for us as expected!
Best,
Kilian
2 Likes
@remie for your use case: if your app was a cross-product app would you expect to price by distinct total number of app users (Jira + Confluence)?
@JuliaDaehne historically, due to the limitations in options with regard to pricing, we’ve been trying to map the amount of value we consider our apps deliver to companies to a per-user pricing.
Through the years, we’ve been experimenting with different pricing strategies. For instance, for our Version & Component Sync Data Center app we have a fixed pricing based on company size. So small, medium and enterprise sized business pay a fixed price starting from a certain user tier. If they grow to a different tier, they do not have to pay more (unless they cross the threshold to the next company size).
A cross-product version of the Figma app would deliver a lot of value as it would allow us to provide additional context to designs in both Jira and Confluence, creating a comprehensive design system for both designers and developers. This means that we would make sure the pricing reflects this added value.
Whether this is through setting a per-user price for distinct users or separate pricing for the companion app doesn’t really matter for us.
However, what I would love to avoid is that users that do not use both Jira and Confluence will have to pay a premium for a feature they are not using.
So regardless of the pricing model, it is imperative for us that we can continue to differentiate our pricing between users that have cross-product feature and those that do not.
1 Like
If I understand you correctly you are not necessarily interested in a different price strategy for one part of a cross-product app vs the other. Instead you want to differentiate between single product use vs cross-product use price.
Could this be a scenario where you maintain your current single product apps and add a cross-product app with the above mentioned value adds at a different price point paid on a ‘per user’ basis? In this case a distinct user count is probably not the right way as it could be interpreted as a premium paid by those that don’t use the secondary product. With a double count the overall cost is higher the more users use 2 products or more which seems justified as they get more value out of the app
Hi @JuliaDaehne
First off, thanks for putting together this RFC and for inviting feedback. We appreciate Atlassian’s effort to improve the experience of building and distributing cross-product apps.
However, our product, Refined Sites, spans Confluence and Jira Service Management in a way that doesn’t lend itself well to the primary/secondary approach. Refined Sites can be used for multiple distinct or combined use cases — sometimes just Confluence (documentation, knowledge bases,…), sometimes just JSM (ITSM, HRSM,…), and often both (intranets, partner sites, help sites,…). Because of this flexibility, there is no single primary or helper app; it should always be possible to install the products separately.
On pricing: currently, we charge based on license size for each app. This reflects the value customers receive from using Refined Sites. When Refined Sites is used for Confluence and JSM together, the functionality and benefits multiply, so we believe it’s reasonable to charge for both. A single primary license model together with future usage based pricing wouldn’t be workable for us.
I’d also like to echo some of the points others have made about ensuring the new cross-product approach maintains flexibility for vendors who deliver value across multiple Atlassian products. We don’t want to see a model that inadvertently restricts how customers install or pay for cross-product apps that deliver distinct benefits in each environment.
Thank you again for the opportunity to provide feedback. We’d love to explore a model that allows for true cross-product flexibility—one that recognizes distinct use cases across Confluence and JSM while keeping licensing and pricing fair for vendors and customers alike. We’d be happy to discuss this further and share more insights from our experience.
3 Likes
@JuliaDaehne from a marketing perspective, having 3 apps on the marketplace with roughly the same value proposition is not really desirable (to put it mildly).
In addition, it would also be very messy with regard to migrating existing customers to the new app just to unlock cross-product features.
I was thinking, perhaps App Editions are a solution here? As in, that we only allow use of the companion app for those who pay for the Advanced edition?
1 Like
Thanks a lot for your feedback @KilianLohmann, I am looking forward to seeing you in EAP
Hi @osiebenmarck thanks a lot for your feedback. As for your question on FRGE-918: with the introduction of cross-product apps all storage will be shared between all linked contexts of an installation. With this the requirements of the ticket should be met
2 Likes
@ThereseAlburg thanks for your feedback. I see what you’re saying: if you created a cross-product app with Confluence as the primary, the ‘JSM only’ users would have to install the app in Confluence first which doesn’t make sense when a user just wants to create a customised IT service desk interface and is not interested in a Confluence functionality.
One way you could handle this with the current cross-product app model is having the app published twice on Marketplace:
- Refined Confluence primary (with JSM optional)
- Refined JSM primary (with Confluence optional)
From a licensing perspective this could work in a license decoupled world where the customer pays for each app users. As discussed with Remie in this RFC, a double count could ensure that users using both product contexts would pay for both.
I appreciate the solution would be a little clunky but keen to hear your thoughts