- What is the actual “business” expectation from the user’s point of view for this process – should the data that existed on the app vendor side be automaGically re-linked after this reset?
Is this purely trying to address the failure that used to happen on re-subscribe or actually the fact that a sequence of normal actions as described would cause a complete disconnect of this customer from their data on the vendor’s side?
Speaking from experience as Solution Partner currently involved in a complex Cloud to Cloud merge project – where this exact use case happens across approximately 12 vendors.
If I am able to re-subscribe but then still have to go through 12 vendors trying to recover my client’s data before it gets purged as “orphan” – that’s not really an improvement.
-
I do note comment from @cmacneill that NOT connecting to the data automatically is a valid use case. In this case how are we to distinguish the site re-import from such an event? The way I am reading this – the site URL is re-assigned to a different entity. Same URL, different clientKey, same secret (apparently it is “keyed to the app key”?). How is this different from re-import?
-
If the automatic reconnect is expected, why would anyone (using a custom platform, not ACE or springboot) create new records and keep “orphans” around in the first place? Why not update the existing record (by URL) after all security/signature checks and not have to deal with the concept of “latest”?
-
If the automatic reconnect is NOT expected under not circumstances until ownership of data is verified – can this be explicitly clarified?