Expert tips - duplicating your tabs so you do not lose everything (as well as the app) ((and More))

I have strange things happening - and sometimes it ‘makes sense’

  • if you are in a tab and you change the data source… then change it back… Glide seems to lose ALL components and you have to start again. Not overly good. Sometimes. (always would be bad though)

I have had all components disappearing from tabs now twice in two days - which is an actual disaster (tons of lost work, I cannot test with the customer, etc). Worse, I have to make the environment more reliable to trust it.

So a few things

  • daily backup routine - of my apps into a team folder, one with a copy of the GS, the rest to the normal GS - rename to be the day’s date
  • daily copy of tabs ‘archive xxx’ and visibility so that they are hidden

The second is the life-saver (and likely a good idea to do hourly if you have a complex app).

I hope this helps!


Another Expert Tip - user-sensitive columns (usc) respond faster than the same type of column in a GSheet.

In my app I have realized that there is a decent time saving for the end user by storing values in usc columns, even if there is no need for the column to be user-sensitive (for instance, if you have Row Owners enabled).

USC columns live in Glide so they react much faster than writing to and from the GSheet.

I hope this helps! (and that I am right … )


um, it’s User Specific Columns :wink:

Having Row Owners enabled doesn’t really have a bearing on a choice whether or not to use USC’s, as Row Owners and User Specific Columns really serve two different purposes. Yes, USC’s keep data “private” to each user, but I don’t think they’re really considered a security feature. It’s more of a convenience thing and to help avoid users clobbering each other’s data.

A good example is Custom Forms. When you use these, it’s essential to store user inputs in User Specific Columns, (before committing to the table with an Add Row or Set Columns), otherwise if you had two or more users adding data at the same time, they’d be bumping into each other.


The big benefit I’m taking advantage of is that this column does not live in GSheet world, so it’s a lot faster :rocket:

Does simply using the eyeball visibility option to hide the tab prevent the data from being sent to the app at all? Or, should a specific row owner condition be added to each of these hidden tabs to fully secure all data, even if it is marked as hidden?

Another Expert tip I came up with - regarding Deleting Rows.

It is great we can delete rows, but it can be slow, at 5 - 15 seconds to actually complete. This can give a lot of problems if the user is ‘too fast’ in your app.

So a trick is to have a toggle (boolean) you set when the user triggers something that would delete a row (e.g. a button ‘Quit’)
Your action first should set column in that row you will delete to something like toggle-deletingrow is true

Then in the screen a user would navigate to where normally they want to have a fresh (and single) row, you use the Filter option in that screen or tab to ‘filter toggle-deletingrow is not true’.



Another Expert Tip / observation:

  • when you Set Column and try to set a column value to 0 (zero), then Glide things it is an empty value and puts in nothing rather than a zero.

This explains why part of my increment process was not working! as I never set the value to 0 but only ‘empty’.

What type of column?
If you set either a Number or a Text column to 0, in both cases you should get… 0

Here is an interesting exercise.

  • Create a table with 4 columns
    • Text
    • Number
    • Date
    • Boolean
  • Then add a screen with a bunch of buttons that do a Set Columns on all 4 columns, with each button using a different value. In my test, I used:
    • 0 (zero)
    • 1 (one)
    • T
    • TRUE
    • true
    • F
    • FALSE
    • false
    • Clear Value
  • Then click around the buttons and watch the data values. The results are quite revealing :slight_smile:

In my case it was trying to set column on a number field - and the 0 value was not taking.

Next expert tip…
don’t create a bunch of email accounts to test! what a waste of time!!

instead - with a gmail account…

gmail resolves any email address with your front bit, then … as your email

so if I am normally
then I would have test accounts with

Then if I am making new user accounts, I put the last name as my email extension

So Mark Tree, Mark 123, etc

Saves you tons of time hunting for pin numbers.


Another big time saver (and a way to reduce errors)

For CSS bits (like removing the menu, tab bar, moving the floating buttons about, etc)
… I have template columns in my User sheet (as the User sheet is always accessible throughout the app)

so CSS Remove Tab - and in the template text, I put in the CSS

Then it makes it very easy to add in my commonly used CSS bits in every tab and screen through the app.


Another expert tip - column naming :star2:

I’ve learned from the Glide Greats that it’s wise to have some consistency when it comes to naming columns, in GS and the extra Glide columns you make.

This can help you find things (“rats, I know it was a template but where…?!?)

So I’ve been using things like:

tp- template
mth- math
sv- single value
lk lookup
rel- relationship


Plus specials like
Toggle- for some Boolean
Has… (HasPaid, etc)

What do other folk do? :slight_smile:


Hi @kyleheney

  1. The visibility feature is not a good way to secure your data. With visibility, all the data in your tables is downloaded to the devices of all of your users and the data is filtered for visibility on their devices.
  2. The row owner feature allows data for a given user only to be downloaded to his device. All other data pertaining to other users is never downloaded to their devices, a user can therefore never see the data of other users. This is secure.

For more information:

@Robert_Petitto’s explainer video:
Row owners and roles demystified

In the Glide library:
Row owners


No no I’m fully aware of row owners vs visibility settings. My question was around the new “eyeball” on/off for tabs in the new editor design. They let you quickly “disable” a tab from showing in the app, but I’m not 100% sure those “disabled” tabs are downloaded or not. My assumption is that they aren’t, but I haven’t seen anything official on it.


Aaah, I had misunderstood your question! :sweat_smile:

To be on the safe side and err on the side of caution, I would use row owners and roles even on tabs hidden via the eyeball visibility feature.

@Mark_Turrell , I have NO idea why this post doesn’t have more likes - I’d love to see this turned into some kind of regular series from Glide! That said, and while I’m waiting, wanting to know if you’ve developed any additional best practices over the past year+ and wanting to say “thanks!”.