App use consent --- new feature for all apps (privacy and compliance)

Hi all, over the holidays, a few of us at AppSheet have been hard at work to ensure that the apps you build on AppSheet are suitably architected for the business environment of 2020 — especially with respect to privacy and compliance. In Europe, there are GDPR requirements while in the US, California is introducing its CCCA laws this year.
Before an end-user uses and shares his/her personal information via the app, it is considered good practice to inform the end-user about the information that this app will be gathering, the uses that this app will make of that information, and request the user’s consent before proceeding. It is also expected that the Terms of Use (ToS) and Privacy Policy (PP) of the app will be accessible to the end-user to help make this decision. Anyone who goes through an AppSheet sign-in has the opportunity to provide their consent to AppSheet’s use of their data. However, the end-users of individual AppSheet apps do not have a similar opportunity to consent to the use of their data by the app creators.

Starting today, we are gradually rolling out a change that ensures that every AppSheet app will automatically launch such an end-user consent dialog when user X first uses app Y. AppSheet will automatically detect what information the app will access and will prompt the user for appropriate consent. The ToS and PP of each app are customizable by each app creator. You can find the ability to do so on the Info -> Properties pane of the app editor.

If the user does consent, then the app functions normally as it did before. If the user does not consent, then they will not be able to proceed to use the app.

For some, this may seem like an unnecessary level of friction and we understand that sentiment. However, since the vast majority of our customers are businesses for whom topics like compliance and privacy are important and in some cases issues of law, we believe it is important to enforce this change uniformly across the platform.

As always when we make significant changes, we want to make sure we share our motivations and the principles behind the changes, and gladly welcome your feedback and suggestions for improvement. We realize that this consent dialog is not yet localized (it is only in English at the moment) and there may be layout improvements that we can refine as we learn from you.


How does this apply to a suite of applications ran through a launcher? Will the user have to accept this for each “micro” app?

1 Like

Yes, the user will have to consent to each individually. This is because each app may have different purposes and different terms of use and different privacy policies.

I know this is at odds with our principles of trying to modularize into many apps. However, it is only once per user per app.

We are trying to accomodate a world where privacy is becoming supremely important. If we introduce a notion of suites of apps with shared terms of use and privacy policies, we can simplify some of this.


Hi @praveen! I just copied a sample app and didn’t notice a difference. I assume that what you wrote about consent will not apply to prototype and sample apps that are made publicly available, because once they are copied, information is no longer being shared with the person who made them. Is that right?

I do keep holding out hope for a scenario in which a suite of apps operate in a more connected fashion.


Thanks Praveen. Unfortunately, Google users receive the Google notice and then AppSheet will display one as well. If the text is customizable and we can insert links to the appropriate policy, this can certainly be helpful. Where is record of the consent maintained if there’s an issue?

1 Like

This sounds like good groundwork. @Grant_Stead’s wish sounds feasible in a future update. Perhaps the AppSheet team can find a way to scan the app to detect any and all links to other AppSheet apps (similarly to what its already doing to determine which permissions are needed), and pull the permissions they also need to the forefront of the “base” app, so to speak, and apply that consent to the “child” apps.

@Praveen, often the account which ‘owns’ the app is a placeholder / not the intended contact person. Some reasons for this are:

  • The app owner account is the account through which reports / workflows are fired. Often you need to give special permissions within security filters to this account for the reports/workflows to fire properly. As a result of this, the app may function differently / improperly when using it as the app owner account, such that you would not want this account to be a true user.
  • Some team collaboration workflows may have a shared parent account / host production apps in a single source.

My current app consent message is as follows:


Would it be possible to customize the contact email / add this as a field in the app properties?


Hi @praveen

It seems that when using the snapshot() function, the link when clicked; shows this consent page instead of the image initially set up within the workflow.

Is there a fix for this?


1 Like


Another question. Currently, when users are logging in, they must click through a ‘sign in with’ page to select the authentication provider, even if the app creator has specified a single-source authentication provider:


As @Grant_Stead pointed out in a separate thread, it would make for a cleaner user experience if this page did not exist when only one option was available.

You mentioned in the same thread that the secondary objective of this ‘sign in with’ page was to give users a chance to view the ToS and privacy policies prior to accessing the app. Does this new addition to the apps suggest we can get rid of the ‘sign in with’ page when only one option is available?


@Jonathon, I agree, this page should be bypassed when you only allow a single authentication provider.

@praveen, if this updated, would it be possible to also select only 2-3 providers, instead of 1 or ALL?

Also, there are times when all app users use one login (Office365) but the app owner/dev uses Gmail. It would be great if we could allow both, but only show users the Office365 option to avoid confusion when employees try their personal Gmail rather than their work/Office365 account.

Perhaps the user White List could be integrated, with an option to “only show login providers in White List”. Then the providers that are displayed would dynamically update as you add/remove email addresses from the White List.


I really appreciate the way y’all have been posting your ideas and plans, before executing them, and getting input from your users… It’s a really strong move.


@praveen I am one of those app makers who uses Google, but all the rest of my users use Microsoft. However, they all have dropbox and Microsoft accounts, with the same email address user name for each account, so when I share my app with an email, and when they accidentally switch back between accounts, AppSheet double charges me for two users, when I only shared it with one.

Suggestion: @GreenFlux’s idea of selecting a number of providers that doesn’t have to be all or one. This would fix my dropbox/Microsoft issue

To answer my own question, I found that I have to acknowledge the same “sharing of data with the creator” even when a prototype app has been copied and hence the actual “creator” of the app will, in fact, receive nothing. Unlike the example shown above, where is shown in parentheses as the creator, the message I received didn’t show the address (which would have been my address, as I made it) but just referred to the “app creator.” This is a confusing statement. Can this be corrected?

@praveen The consent dialogue keeps popping up, over and over. It seems like of I have the app open, black screen my phone, then unlock my phone… I make a move, then it pops up again. Anyone else?

Have you tried uninstalling and reinstalling the app?

No, I haven’t.
I take it this is a serious enough change that we need to do that…

@Gil How does this effect white label apps in the play/Apple store?