Realm Persistence for Connect Data Residency is now in Generally Available

Data Residency
, , ,
1

We are pleased to announce that Realm Persistence for Connect Date Residency is now Generally Available.

What is realm persistence?

Realm persistence is a significant addition to our data residency functionality. With realm persistence, customer app data remains in it’s original region following a reinstallation, unless reinstalled beyond a defined period.

How does it work?

This capability allows a Connect app supporting data residency to persist the region in which the app was originally installed on for up to 30 days after uninstall.

To enable realm persistence for your app, you need to add the following section to the app’s descriptor.

.. "dataResidency": { "realmPersistenceDays": 10 //install region will be persisted for 10 days after uninstall } ..

realmPersistenceDays defines the number of days for which the original install region will be used on an uninstallation/re-installation of the app disregarding the products provisioned region. The maximum value here can be up to 30 days and minimum can be 0.

You can read more in our documentation.

Your insights are incredibly valuable to us, so please don’t hesitate to ask questions, share feedback, or throw out ideas. We’d love to hear from you!

Cheers,
Daniel Reed

3 Likes
2

Hi Daniel,

This is great news! To be clear, as an opt-in feature, does that mean that if no persistence is specified in the app descriptor, the default is the equivalent of specifying “0” (no persistence)? If so, this would ideally be mentioned in the linked docs.

Can you also confirm that this type of app descriptor change will result in only a micro update and thus no manual admin approval will be required?

3

Hi @scott.dudley

That is correct. The default behaviour if realm persistence isn’t specified or is 0 is no persistence.

This is correct.

4

Hi @DanielReed,

Thank you for your announcement.
As discussed in Jira Service Management, we have already come across an edge case(?) with Connect apps that not yet adopted Data Residency, and where we suffered “seemingly” full client data loss on particular (unpinned) sites (due to modified routing). This should be handled in a more transparent manner. The Realm Persistence feature (and its restrictions) should apply only to apps that have their migration path implemented (or properly documented if that use case cannot be supported anymore).

Cheers,
Márton

5

Hi @DanielReed
Hi, I have a question regarding realm persistence based on the following scenario:

  • Our app was originally installed without data residency support and was marked unpinned and ineligible.
  • The customer migrated their Jira instance to the EU realm
  • The customer uninstalled our app
  • Afterwards, we added support for data residency and the EU realm, we are not using the realmPersistenceDays field.
  • The customer reinstalled the app.

In this case:

  • Will Jira treat the app as installed in the global realm (from the previous installation) or directly in the EU realm?
  • Is this behaviour always consistent, or could it vary depending on the timing and specifics of the installation?

However, our tests show that:

  • After reinstallation, the app remains in the global realm, even though it now supports the EU realm.
  • Interestingly, installing another app (with no prior installation history) that supports data residency directly installs in the EU realm.

We tested using a side-loaded development version.

Why is this behaviour different, and how can we ensure that our app installs in the correct region upon reinstallation?

Thank you for your insights!

6

Hi @MarekSzczepaski

In the example you mentioned above, Jira will install the app in the EU realm because realmPersistenceDays are not declared and the app supports EU (the realm the product is pinned to)

This behaviour is consistent as long as install happens after product get pinned/ or in a regional shard that their app supports and realm persistence days were not declared at the time of uninstallation

If you have found that the behaviour is inconsistent, can you please raise a ECOHELP ticket with the cloudId addOnKey and we can help investigate why this is so.