Hey everyone,
Thanks for your initial thoughts and feedback. I hope to share more insight into the thinking behind this solution below.
- Scope and Intent of Static Link Egress:
This RFC is specifically targeting the use case of bridging the gap for partners’ documentation and support resources, so that these do not count as egress for RoA (Runs on Atlassian) status. While I recognise there are many other scenarios that could benefit from more flexible link handling, one of the key risks we are accounting for is the potential for customer data to be egressed via wildcard URLs. That’s why the current proposal is focused on static, exact-match URLs only—this approach helps us maintain user trust and compliance, while still enabling partners to guide users to helpful external resources. For use cases requiring wildcard and dynamic URLs, as mentioned above, this is the relevant RFC: RFC-94: Configurable Egress and Remotes. - Manifest Updates and Major Versioning:
I hear the concern raised about whether changes to static links in the manifest would trigger a major update for the app. Our current thinking is that updates to static links will not trigger a major update. We want to avoid unnecessary friction for developers when maintaining or updating documentation/support links, and will ensure that the update process for these static links remains lightweight. - Manifest Size and Link Volume:
Regarding the number of links that can be declared: the manifest file currently has a size limit of 200kb (see Manifest – Forge apps). At this stage, we are not planning to limit the number of links directly. However, if the volume of links you need to declare causes your manifest to exceed the 200kb limit, we’d appreciate hearing about it! This will help us understand real-world needs and consider further improvements if necessary. - Removal of Warning Messages for Static Links:
This solution will prevent warning messages from appearing for any static links declared in the manifest, thereby reducing customer friction (see FRGE-1680:
External links to support channels and docs should not show scary looking warning messageUnder Consideration). Users will be able to navigate to these external resources without encountering warning pop ups, provided the link matches exactly what is declared in the manifest. This should improve the end-user experience and make it easier for developers to guide users to legitimate support and documentation resources. - Consent vs Installation Display for Static Links:
We do not intend to display these links on the partner consent screen because static links will not be allowed to egress UGC or PII, and hence won’t require admin consent. Instead, we plan to show them on the installation screen to inform users of the links the app includes. As per Remi’s suggestion, we can explore showing only the domain(s) upon installation rather than listing every static link to avoid bloating the installation page, although the declaration of each static link in the manifest will still be required.
Thanks again for the feedback and discussion. Keen to hear your thoughts!