Application Access Key stays consistent between App Upgrade

[KingsGuava]

We have a few large data structure changes planned for our AppSheet apps and were think of using the "App Upgrade" deployment method. For those not familiar, we followed this documentation: https://support.google.com/appsheet/answer/10105386?hl=en Basically, you make a copy of the app, implement all of the changes, and then upgrade the original app by pointing it to the copy. My team and I were excited to use this deployment method because it would allow us to change the data stores to a test database and we could do all of our testing without interfering with the production apps. When we upgraded the original app to the copied version, we knew that we would have to change the data tables back to the production ones, change the name of the App back to the original, and redefine the brand logo and loading image. 

However, one issue that we weren't aware of is that the integration and Application Access Key of the copied app would also override the original app. I understand that when an app is copied, it will need it's own options to define an Application Access Key. But when an app is upgraded I don't think that the Application Access Key should be copied to the original app. Especially when the original app has cloud integrations enabled but the copied version didn't. Perhaps there could be an option similar to when an app is copied to copy the cloud integrations or not.

Also, because the copied app's cloud integrations settings were copied to the original after the upgrade, all of the webhook automation tasks from other apps had to have their Http Headers changed to use the new Application Access Key.

[Marc_Dillon]

But when an app is upgraded I don't think that the Application Access Key should be copied to the original app.

---

I don't agree with that.

But I do support the addition of an option as you described. Another option could be to allow manual entry of an access key (would have to be formatted properly).

Although I find it very unlikely that either of these would be implemented, at least any time soon.

[KingsGuava]

When you get a chance, I would like to hear your concerns about having the Application Access Key excluded when upgrading an app through the "App Upgrade" process. This was our first time using the process, so there is probably use cases that I'm not aware of. 

For my scenario, I wanted to copy an app to add new features to an existing app in a test environment so that the production data wouldn't be interfered with and I could pass the app off to a tester who could confirm the changes worked as expected. If one of the features involved using cloud integrations, then I would have to enable the cloud integrations in the copied app. When users copy an app, it doesn't copy the cloud integrations or Application Access Keys settings of the parent app. Then I would build some integration using the copied app's Application Access Key. My issue with copying or overriding the cloud integration setting during the App Upgrade process is that an Application Access Key should be unique to each app. Just like how two apps can't have the same App Id, I assume that they can't have the same Application Access Key. In this scenario, the integration that was using the copied app will have to be updated after the app upgrade so that it uses the correct App Id/App Name anyway, so I don't think there would be an issue if it needed to update the Application Access Key also.

I was hoping with AppSheet's recent focus on app development and lifecycle features that this use case could be considered, but I agree that it is a fairly niche situation and probably won't be addressed for a long time.

[Marc_Dillon]

It's recommended to change the access keys on any system on a regular basis.

And you would typically only use the app upgrade option on a larger scale update, so it would seem to make sense to combine a key change with a big upgrade.

You may have also made several changes that could affect how those outside services interact with the app. It's better to have them fail authentication than to somehow cause data loss.

The whole point of the app upgrade process is also to completely replace/overwrite the original app with the copy. And the copy starts out as its own separate app, which would necessitate a separate key. It doesn't make sense to have exceptions.