Hi @scott.dudley, thank you for your feedback.
- Site admins need a dashboard displaying which realm is in use for all installed apps (ie. which install base)
- For apps that have realms that differ from the host product, if the app supports migration to the realm of the host product, the dashboard should display a button that permits individual realm migration for that app (or, alternatively, for all apps).
Both of these suggestions are being implemented. We are currently working on the customer experience which will allow admins (via AdminHub UI) to:
- Display details of where the host product is pinned
- Display list of installed apps (per site/host product) and their current pinned location
- Status to show which of the installed apps are ‘eligible’ to migrate realm (in the case that the host product is in a different realm as installed apps). The eligibility of an app to migrate is determined based on if the relevant app supports the realm that the host product is pinned, as well as if the app supports automated migrations between its supported realms i.e. have integrated the realm migration APIs/migration hooks)
- The admin will then be able to schedule a realm migration of ALL ‘eligible’ apps to be migrated to the same realm as the host product within a migration window scheduled by the admin
This must take into account that DE is a subset of EU (if the host application is pinned to DE, an app with data stored in US should be able to migrate to EU even if the app doesn’t support DE).
Regarding considerations between EU and DE realm declarations for the app, I have attempted to clarify in my above comment.
- The Connect installation realm needs to be sticky, per-app. Regardless of where the customer’s host site data is stored, Connect needs to remember the previous installation realm for each individual app (within, say, a 30-day window, or something reasonable that is well-documented). Reinstalls within that window must always use the previous realm. Your update from last November suggested that this was being considered. Are there any status updates?
We appreciate the concern raised here. Realm persistence for re-installations is something we are still exploring to determine what is the best outcome for wider developer community.
Our understanding is that some apps are already/will continue doing some form of manual migration, and for this, these apps rely on the current uninstall/reinstall mechanism to move the installation location and then migrate a tenant’s data between realms. Therefore, we have not deprecated this mechanism yet.
Our current hypothesis is that once the realm migration solution is available to customers, most realm migrations can be facilitated using this new solution without requiring any reinstallation of the app (though there maybe edge cases where manual migrations are still required and apps continue to rely on existing uninstall/reinstall mechanism). Therefore, most subsequent un-installations/re-installations would likely be performed by customers for non data-residency reasons, e.g. troubleshooting as you outlined or a change of mind. However, this may be an issue if the host product has been migrated to a new realm during this uninstallation/reinstallation process → where Connect will treat it as a fresh installation pinned to the same realm as host product, and will not account for previous data set in old realm. Our assumption here is this scenario would be relatively low occurrence once realm migration capability is made available to customers. Further, this occurrence rate would continue to decrease as more apps integrate the realm migration solution. What are your thoughts on this assumption?
Another potential scenario which may cause issues is if a customer installed an app prior to adoption of realm pinning/relevant realms by the app, then the customer uninstalls and reinstalls, and the app traffic is now routed to the new realm (same as host product), and causing a disconnect with the old data set in previous realm. This is something we are looking into further to understand how we can address it.
Please note, If we were to implement realm persistence upon reinstall in future (TBD), it could result in a breaking change for apps utilising current uninstall/reinstall mechanism, and therefore, we believe should only be implemented once the official realm migration solution is GA and majority of apps have implemented the solution. This will also require a deprecation notice/period prior to implementation.
When the client later looks at the current state of affairs (Jira says it’s hosted in DE and the app’s documentation says it supports DE hosting too), the reasonable assumption is that all of their data is hosted in DE and they are compliant, even though the app is an outlier with data stored in the US. There is no way for the customer to know this (so you have just created a compliance problem), nor is there any way for them to fix it.
As outlined above, the upcoming Admin UI should address this issue as it will outline the installed app’s current pinned realm, which in your example above will show differs from the host products pinned realm. It will also provide ability for the admin to then migrate the ‘eligible’ apps to be in the same realm as the host product.
Thanks,
Sushant