Use refs as "security filter" & faster app for non-admin users

Many of you might have thought of this before, but when I didn’t maybe someone else can use this.

After too many hours developing it occured to me today that I send a lot of data to users that only the administrators need to see in their more advanced app version.

Using refs must be close to a perfect solution for us on premium plan!

  • Shorter loading time for the common user.
  • More flexibility to add features without all the trouble when regenerating structures.
  • No disruption for the common user when editing a deployed app.
  • And not least, no transmittion of potentially sensitive data to common users.

Any thoughts or additions from the geniuses in here?

1 Like

Did you check this and consider to apply to your app?

1 Like

What I do on my app with large set of data is to apply security filter with usersettings.

For instance we have huge data with date fileds. The table security filter is applied to filter out the data wit date fields is AFTER A date which is set by the usersettings. Userseting is just picking up the date of 6 month before.

On sync the app is picking up the data only for the 6 months old.

If the use want to see the last 3 years data for instance, then they visit own user settings and change the date filter and save.

etc etc


I am on premium plan, so I can’t use security filter. Or did I miss something?

I just encourage you to move to PRO then. :grinning:


Encourage my boss! :rofl:


I’m not clear if this is a Tip recommendation or just a question? :slight_smile:

How are you using Ref’s as a “security filter”?

So, here are some thoughts that might help:

1). Separate Apps - In my experience, Admin capabilities usually translate into a lot more functionality within the app. In these cases I always consider if separate apps would be better - Admin vs non-Admin. Yes, this DOES mean that some changes will need to be applied multiple times - once per app. However, I usually find that logic IS different and maintaining the two succinct versions of the expression is way easier that if they are in a combined complex expression in a single app AND, I feel there is less chance of error with the expressions. Other benefits are:

  • extra “security” in that there is no way for non-Admins to accidentally gain access to Admin functions and data.
  • Smaller, faster non-Admin app as all of the data to support the Admin functions does not need to be brought into this version of the app.

2). Separation of data - In many professional apps, raw data is assembled, and in many cases duplicated, solely to fit the needs of the end user views. This is usually easier and faster than trying to sift out the needed data with the presentation software itself. Don’t rule out separating data into admin version data and non-admin version data - even if some records are duplicated. This can result in easier and simpler apps and many times translates into speed of functionality.

3). Large historical datasets - In cases where there is a lot of past data that is visited infrequently, I consider archiving that data to a separate datasource and using a dedicated (possibly 3rd) app for viewing that history. Normally the functions to view history are greatly reduced to basically just the ability to review the records. You could add features here to “re-activate” a record so that it is placed back into the “working pool” of records and accessible again in the “main” app if additional adjustments are needed. AppSheet provides navigation abilities to other apps so you can build in the capability of navigating to the history app that will appear to the end user as if it is all a single app.

Hope some of this helps!


Security Filter speed up the sync time only if you have a database data source.
Like @praveen mentioned here .
This is why you need Business Plan.

@Ratatosk How are you using Ref to speed up sync time?

Why not both? :thinking:

Appsheet has been a learning experience for me. Many things that may seem obvious to a long time user is not obvious for a newcomer.

Also saying something controversial might make the expert call out loud and clear, on counterpoints. :smiley:

1. Separate apps:
First time I made the app I made a huge one. There was no disclaimer in all the thousands of pages i read that said anything about it.

2. Separation of data:
Refs were kind of known to me the first time around, but I didn’t know enough about it, or the reliability of Appsheet to dare split up the sheets.

3. Large historical datasets:
Great point. And something to consider.

How I use refs as a “security filter” and to save loading time

Example 1:

We have all our contracts divided into “task points” which is shared in a large sheet.

A lot of the columns are not needed for the workers doing the tasks, but they are needed for the administration. If I can send 10 columns instead of 40 to the common user, then refs are a great solution.

Example 2:

I wanted to have a contacts app between all employees that also showed their status.

I also want one place where the administration updates all information about the employees.

This was not possible for me in Premium without refs, because of GDPR.

Example 3:

We have 3 different departments, that needs different information. These can have their own refs added that noone else needs to see.

I will not convince my boss to pay twice or thrice. We do not all have that luxury.

By making two versions of the apps.

A bigger and slower apps with refs for the administration. Smaller and faster apps mostly without refs for the workers.

I’m with you. We too don’t have the money for business plan.


I just want to be sure you know that additional apps do not cost any extra as long as they are under the same account. You only pay per unique user per account per month. So on Premium plan, you will pay only $5 per user per month no matter how many apps they are using.

To make one big app or split into multiple is a developer decision based on many factors. I do agree that there is not enough empirical information on performance and size metrics to help guide us in making these decisions.


I do know. :slightly_smiling_face:

There is a slight difference between 3600 dollars and 7200 dollars per year, especially when we still have to rely on other subscriptions to manage the business. My time also has to be included in this.

The sum also has to make financially sense in that the perceived value in time saved and less insecurity, and better information flow for the end users, which again gives us a better chance to keep some of our contracts and customers for a new season.

This all was a hard learning curve for me. I’ve now made the “app” twice. Twice the hours. And learned a lot in the process. There is no regret in it for me at all, but it should be a caution.