What's the suggested way for working with concurrent live and development versions?

I’ve been working on an app for a client, and the basic version is ready to be deployed.

So I’m developing the app on my appsheet account, but the live version needs to run on the client’s. I’m aware that a user is able to duplicate an appsheet app that they have edit access to, and that’s what we’ve been doing so far. However, the problem is that this makes a new app version every time, and that means it creates a bunch of new google sheets, and I have to change every table reference every time I update.

To be clear: I want the sheet references on the dev version to be different to the ones on the live version (two different sets of data, so the dev version can’t ruin anything on the live one).

Is there a smart way to ‘update’ the client’s live app version with changes from the development version of the app on my account?


Any ideas on this?

Have you considered database partitioning to create a sandbox / test environment consistent across both versions?

I’m not sure how that’d solve the problem? The issue is that every time I need to copy the app to the client’s appsheet account, I need to re-link every table. I’m just wondering if there’s some way to just duplicate app updates or something like that.

Hi @Alex_Baker, I think what you need is a concept we don’t have yet, but have been asked for before. Something like a “DataConfig” which acts as a level of indirection for the tables. So you want to be able to have the same app use one dataconfig in test and a different data config in production. So if there were tables T1 and T2 in the app, in dataconfig1, they’d map to different sheets from dataconfig2.

One of the challenges we have when we consider this sort of thing is that the column structures of the tables would need to be identical across the two dataconfigs. We’d have to enforce this. Of course, in your case, the ask is for a bit more. You want to be able to upgrade an existing app to a newer version of the app, but still pointing at the same “old” tables.

Could you please clarify that I understood the ask correctly. Thanks!

Adding @kamila – FYI for useful admin feature request


Sure, that’s pretty much what I’m asking for. It would be a nice feature, and feels like something that would be quite useful to a lot of developers. Working on your own account and deploying to the client’s account seems like the logical way to work on something like this.

Any suggestions in the meantime for how I can approach this or do I just have to reconfigure it every time?

1 Like