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
primaryProductquotas 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:
- 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.
- 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
- 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?