Today we’re sharing plans for a new Marketplace badge designed to help customers identify apps that a) do not transmit data outside of the Atlassian Cloud and b) provide data residency. We are also exploring controls on the installation consent screen so customers can enable or disable sharing of diagnostic logs and analytics.
We expect this badge, called Runs on Atlassian, to launch to customers in early to mid 2025. We’ve put together a blog post explaining the opportunity for partners, plus guidance on what you can start doing today to make apps eligible and participate in the customer launch next year.
The first thing that comes into mind is an allowlist for the gravatar/wordpress user icons. Will this also be allowlisted by default?
The second keyword of the blogpost was „custom ui“. I hope this only means external js/css and not custom ui frontend bundled as resource.
Here is the manifest.yml snippet I had to add to display all the user icons in Jira. I would much rather prefer not to do so since Jira itself uses these images for users and it should not be my responsibility to allow them.
As a Marketplace Partner with a focus on integration to third-party system integrations, the name “Runs on Atlassian” feels misleading. Data egress is the nature of our apps; otherwise, they would not be integrations. We are moving to the Forge platform, yet based on these requirements, we will never get this badge, even if we support data residency.
My main issue with this is the name and the suggestion that “Runs on Atlassian” means no data egress and supports data residency. Also, I don’t think more trust signals help customers because they may not know what they mean or what they filter for.
Why hide app capabilities behind another trust signal name?
I think a better solution is surface app capabilities like data residency and data egress directly in Marketplace filters. As a customer, I do not have to understand what’s hiding behind the trust signal name, and it’s immediately clear to everyone what apps the filter contains.
Will the new installation time controls for analytics and log sharing apply to all cloud apps, or only apps that choose to participate in Runs on Atlassian?
Atlassian wouldn’t have a way to enforce the above constraints for non Forge apps, unless it was made part of vendor agreements etc.
As a customer, I would question https://ecosystem.atlassian.net/browse/FRGE-1579 .
When I run on Atlassian, I don’t want that my app can “exfiltrate” data to another tenant without me knowing.
Thanks for your viewpoint. I can understand. However I’d argue the App still “runs on Atlassian”. But ok, probably you’re right since I could load/store data on whatever tenant if that domain is whitelisted. I’m hoping for a proper cross-product apps support from the Marketplace next year to solve this.
If we have a connect with Confluence macros, we can use connect on Forge to make the app a Forge app.
However it seems we have to keep the macros in connect, as there seems to be no way to move connect macros to Forge? And that would imply a connect Confluence app that uses macros can’t get “Runs on Atlassian”?
A badge like this has been on so many wishlists, it’s really great to see this becoming a reality.
Just a quick question on the exceptions for Atlassian-owned domains. I understand that the host domain (like xxxx.atlassian.net) and api.media.atlassian.com are already exempt and need not be explicitly declared in the manifest.
Are there any plans of also including automation.atlassian.com in the list of exemptions?
EDIT: I’ve followed @LukasGotter’s great exampe and created a suggestion for this here: FRGE-1581
You hit on a key point: integrations egress data to fulfill their purpose, and would not be Runs on Atlassian. During our customer research, we found that customers think about integrations differently. They understand why an integration needs to send data off-platform, but they may be uncomfortable with an app that only works in Confluence, for example, sending data to an external server. Runs on Atlassian is intended to help customers evaluate apps in the second bucket.
For app categories that egress by design - integrations, backup and restore, etc - we don’t expect customers to be comparing Runs on Atlassian apps to non Runs on Atlassian apps, since no integrations will be Runs on Atlassian. We intend to educate customers about why Runs on Atlassian only applies to certain types of apps while also giving partner-hosted apps and apps that need egress to do their job other ways to inform customers about trust, like Cloud Fortified and the privacy and security tab.
Making sure customers understand the badge is absolutely essential. Our research so far has shown that Runs on Atlassian aligns well with the language customers use and their expectations for what it means. It’s more than just data residency and no egress. Runs on Atlassian means Atlassian hosted, data stays on platform, data residency - and very importantly - that Atlassian can programmatically verify these requirements.
The first thing that comes into mind is an allowlist for the gravatar/wordpress user icons. Will this also be allowlisted by default?
We are currently investigating ways to facilitate the loading of icons and avatars without the necessity of declaring egress, similar to our previous enhancements for media loading. Please keep an eye on the changelog to stay updated on any upcoming changes we implement in the near future.
The second keyword of the blogpost was „custom ui“. I hope this only means external js/css and not custom ui frontend bundled as resource.
Could you please provide more details on this topic? It’s important to note that any items specified in the external permissions will contribute to data egress, which means those applications will not qualify for the “Runs on Atlassian” designation. We recommend that you incorporate any necessary styles directly within your app.
As of today, there is no direct API to integrate with Automation for Jira/Confluence. However, customers often want to trigger Automations from within an app, whenever something interesting happens. The workaround we (and other vendors and even Atlassian sometimes) use are webhooks.
Basically, we tell our customers how they can create a rule that’s triggered by a webhook and have them copy the trigger URL into our products.
This has the benefit that customers get access to the whole wealth of features that Automation provides, without us as a vendor having to rebuild these features or having to open additional egress domains. And we can assure our customers, that everything stays on Atlassian-provided infrastructure unless they build rules themselves that egress data, like sending a Slack notification. But that would be their deliberate choice.
Hi @SeanBourke ,
Thank you for your reminder about the macro migration paths. Our macros are mainly static content macros, and I would not know how to get them to Forge with the same / similar functionality.
We also provide webtriggers for the customers to integrate our 2 separate apps( cross product
solution jira-confluence). Thus theres *.hello.atlassian-dev.net in permissions which is really strange domain and customers do ask about that. Also other APIs we’ve done via webtrigger URLs. Is there an alternative for scenarios like creating REST API for your product, cross product comms with other apps but inside Atlassian products, or solution to provide full support for automation (not just read events but also send events). Everything we do right now within forge and we can consider us “runs on atlassian”, but the manifest permissions are nightmare and there just arent any alternatives.
For integration use-cases, please make sure that apps using only dynamic egress (once it is available) also get this badge. I have also commented the feature request for dynamic egress accordingly.
This would be a way for all apps to have the ability to get the badge, since IMHO there’s a difference if the app decides which external URLs the app connects to, or the customer.
