RE: COPYING MULTI-APP applications that need...


COPYING MULTI-APP applications that need to use the same database.

  1. My client

has a set of apps that he will sell to his customers. 2) Each customer gets a copy of the apps and those copies need point to a new database for that customer. 3)

The App Table Columns have a fair number of calculations and the data types have been defined.

So we don’t want to lose that work. 4)

I can make a copy of the first app and check the option to make a copy of the database – great

– no problem. 5) … however … The remaining apps in the set need to be copied but remove the checkmark for the database copy option.

Then I have to go through the process of opening each copy of the remaining apps and open each table in the app to change the source so that it points to the correct Google Sheets in the new copied database.

Is there an easier way to do this?

I hope there is and I just don’t know about it.

Hey Aleksi could you take a look at this for me.


Aleksi – could you take a look at this and tell me if there is something I could do to make my life easier?


Yeah Aleksi, that was the original model but the transactions per customer would hit the maximum 2 million cells limit.

Then the idea of providing customizations evolved and it really made separate databases the best choice.

Our strategy for naming each set is to include a customer identifier in the renamed App title so that they will all stay together in our myapps section of the Appsheet account.


hey Grant, what are you working on?

partitioning or copying multiple apps for the same database?

@Mary_Jane_Pender This feature is available in Business Subscriptions (Corporate plans) and I think it may be the best way to manage multiple types of app users each one with a different table associated with each.

Best Santiago

what is the subscription price of corporate plans?

@Mary_Jane_Pender Yes, they start at $15,000 annually and grow depending on the feature set and number of users. Happy to share a quick summary of the plans :slight_smile:


Sure, Santiago, please send me the corporate plan info.

For example:

this client could have between 50 to 100,000 users – maybe not all at the same time.

send to my email,


@Mary_Jane_Pender You should probably think about the Google rate limit as well if one app has lot of users.


ooooh , did even think about that.

But I am having discussions with this survey client about hosting on AppSheet and maybe being more strategic in how they roll out the assessment app to the client users – so that there is not need for 100,000 licenses all at once … but break out the users into smaller groups – thus a copy of the app for each group.

Thanks for the heads up.



Could I ask you to take a look at this issue I have posted here.

Please tell me I have missed some really simple function.



I am afraid there is no short cut for this.



Oh heck!

Ideally at the point where you copy an app, having a third option to select the same database as another app would wonderfully resolve this issue and make the sales of app sets and thus plan licenses a much easier thing.

Thanks , m.j.

Agreed- that is a good idea (and perhaps not that complicated to implement)

Have you considered table partitioning an only manage one app instead of multiple apps?

@Santiago that’s what I’m working on lol

@Mary_Jane_Pender Why do you need to copy the app? Why don’t you use the same app for every customer with security filters? Would it be too big then?


we originally thought about moving onto mySQL but the client realized that he wanted to be able to offer some customization for each of his customers. At that point I felt that the copy app option was the best approach.

Then each customer could have their own set of apps and their own database.

The customizations would probably mean having a core set of sheet columns and then addition data columns that the customer might request.

Another way that I could do the copy app and keep same database for a client, is to set up one app with all the various functions. Copy it once to create a new database, then copy the copy keeping the new database as many times as there are functions.

Then, open each “copy” and keep only the views and functions that apply to each app - rename each app.

So one mega app produces one database with several apps that support various functions in the company.

Less tedious than the method I used yesterday.

Just for my information, which subscription plan is required for partitioning?

I have another client for whom partitioning might be the answer – doing very large population survey.

Thanks, m.j.

@Mary_Jane_Pender, this is an old thread but I was wondering if and how your plan to achieve this worked out. Thanks.