Selling restricted applications to customers

[vafernandez]

Hi,
Is there a way to configure the distribution of an App so that when we sale the App to the customers they are just able to run it under their own environment (datasource and GDrive) but do not have access to the App definition, nor be able to copy the App?

After the sale we as creators should not have access to their data. But we should be able to provide App updates and support (in case they need it).

Regards

[1minManager]

vafernandez:

do not have access to the App definition, nor be able to copy the App

Simply make them just user on your account. Anything more and they can copy it.

vafernandez:

should not have access to their data. But we should be able to provide App updates and support (in case they need it).

You could create the App from a spreadsheet on their Google Account. Then once the App is build, remove you from the spreadsheet. But then you can still View Data in the table section. You could then set all required columns to “Senstitive Data”. But its a bit sill that you’re having to hide the data yourself from you

The only secure way I can think of would be for them to cut and paste the data to another spreadsheet. But personally I’ve only have one company share their App with me and set anything as “Sensitive Data” and only one other got me to sign a non-disclosure agreement.

Simon@1minManager.com

[Steve]

There is no way for you to retain exclusive control over the app config while also allowing them exclusive access to their data. So long as you have access to the app config, you have access to the data.

[vafernandez]

I am exploring Private Tables as an option, though future updates for the App that would require a Spreadsheet change will be a challenge. I am thinking maybe to later provide customers some Google Apps Script that would allow the user to update the Spreadsheet without having to do a manual intervention or maybe include a predefined set of additional columns in the tables, to use in the future if needed, keeping them “without use” until necesssary.

An additional limitation with Private Tables is that the tables are effectively created Per-User on first use, and as such, data could not be “shared” among “users” of the same “customer company”.

I have just found this interesting article regarding this subject:

How to use Security Filters to allow multiple companies to use the same app Tips & Tricks 💡

Let’s say you’ve got an app, and you want to allow multiple companies to access and use the same app. The primary benefit here is that, as a developer, you only have one app to support. If you were to create a copy of said app, one for each additional company that wanted to use it, then you’d have to support all those apps. Any changes made to functionality (column structure, views, actions, automation, etc.) will need to be duplicated on each additional app. This then translates to ho…

But as you mentioned before, the method works but keeps control of the customers data.

Maybe is a feature request what I think would be needed: a way to provide a “usable” copy of an App without access to its definition as an option for Developers to provide general solutions apps.

AppSheet licenses would always be required for every user.

[MultiTech]

Private tables would be the solution you’re looking for, but you’ve already noticed the major problem with this setup

• YOU can’t make changes to THEIR tables
  • But if you change the tables to update the app… THEY have to update their tables.

A script would help… but you’ve got to get them to install the script, and authorize it. And unless you’re going to get the script approved, you’ll have that giant red screen that scares everyone (saying your script isn’t secure or signed, are you sure you want to allow this?).

---

Realistically though… if you’ve got some technically minded users, that wouldn’t mind the occasional modification to their sheets, you could make private tables work.

• They only need to make sure the columns are named the same, and in the same order.

  • And that process is actually pretty straight-forwards - if communicated properly.