Using private tables

Motivation

By default, all tables in an app are owned by the app creator and shared across all the users of the app. For example, in an Order Capture sales app, the Products, Customers, and Orders table are all common to all the users of the app (salespeople who work for the organization). This is a familiar "database application" pattern --- the tables (in spreadsheets) correspond to a central shared database of information. it is the prevalent pattern for corporate apps.

However, there are apps that do not fully fit this pattern. In addition to a shared common set of tables (a shared "database"), they also require individual per-user data. Here are some examples:

  1. A product catalog with a note-taking feature ---- there is a common shared product catalog, but each user can use the app to take notes about the individual products. The notes are private to each user.
  2. A school test practice app --- there is a common shared set of questions, but each student's answers remain private to that student.
  3. An exercise app -- there are common shared workout routines, but each user can record their own progress.

This ability to have per-user private data is particularly relevant when an app creator builds an app and distributes it widely. The users of the app may not know the app creator and certainly do not intend for the app creator to access their private information.

AppSheet supports private data using Private Tables.

What is a Private Table?

A Private Table is defined just the same as any other table in an AppSheet app. It has a column structure, and is defined by a spreadsheet (or other data source). However, the table is explicitly marked as private (not shared). You can set this option via the Editor in the Data->Tables pane

An app with private tables must require user signin. 

Every user who uses the app gets a private copy of each private table in the app. The copy is stored in that user's cloud storage account and is initialized with the data provided by the app creator in the original table definition. The data in that private table is accessible only to the specific user who created it. Each user's changes are made independently.

If the same user accesses the app from different devices using the same account to sign in, naturally the same private table is used across these devices. This is the benefit of storing the private table in cloud storage rather than locally on each device.

In all other ways, the app acts in the same manner as any other AppSheet app.

Restrictions and Notes 

A private table must be the only sheet in the workbook.  Your app can have a number of workbooks and sheets, but each private table must be the only sheet in its own workbook.

Another thing to consider is that private tables can make app changes more complicated.  When a user starts using an app with private tables, they will get a copy of the sheet as it currently exists including the current column structure.  If the app owner wants to update that column structure (add / remove / reorder columns) these changes will not propagate to existing users.  This has the potential to break an app for existing users.  You should make sure your column structure is finalized and unlikely to change in the future before giving users an app with private tables.

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.