Push notification access granted column

I just added a button to give users the option to allow push notifications. Before I tested the button, I added the push notification access granted column to my users table to test that as well. I then tried opening the app on my phone, and I clicked the button to allow me to receive notifications. However, when I look at my user table, the column that is supposed to track if the user enabled notifications is not checked off.

When I look at the action options for push notifications, it feels like I’m supposed to create a multi-step action to allow the data to be written to the user table, but I can’t figure out how to do that.
Screenshot 2023-10-02 at 10.15.05 AM

Yes, that was the help article that I was reading about how to use push notifications, but I still can’t figure out how to do the notification granted column in my user spreadsheet.

I also watched the short video at the top of the help article and also watched the other short screen recordings that are in the help article, but I’m still not sure what I’m doing wrong about writing the data to the user table to keep track of which users have enabled notifications.

It feels like I should have to set up a multi step action that includes a step to somehow set the action for “push notification access granted” to set column value for that column in the user table, but I don’t know if that’s right? Or how to do that if that is what I’m supposed to do?

I set up a button and set the action to “request to allow push notifications.” I then tried it out on my phone by clicking the button and allowing notifications on my phone. But then I checked the user table, and it hadn’t been checked off next to my name.

@MatthewS has published a tutorial on Push Notifications over at Glide University. That might be worth a look.


Hi Megan,

The “Push Notification Access Granted” button simply writes a boolean to a column, checking if user has granted access. It is not necessary, but can be helpful such as if you want to send emails to only users who haven’t enabled notifications.

The request to allow push notifications button simply pops up the phone settings, and doesn’t write anything to glide.

I wouldn’t combine these two actions into one in a custom action, because the access granted boolean check needs to be done after the user has had time to give the permission… just clicking the glide button only prompts the phone setting, it doesn’t actually give permission.

I’d be happy to take a look at your app if you’d like some eyes on it to help find any lingering problems. You can DM me here if interested.


Yes, that’s what I’m trying to do. How do I get the “push notification access granted” action to check off the boolean column in my user table?

What I tried doing was to use the “request to allow push notifications” as a button on my home screen, then I clicked on the button while accessing the app as myself as a signed in user on my phone. I allowed notifications on my phone, so my thought process was that it would then toggle that switch in the appropriate column in my user sheet in Glide.

If the “access granted” and “allow notifications” are two different actions, how do I get the app to write the boolean to the column in my user table once the user has allowed notifications?

With two different buttons. First, the request button to open and set the settings, then a second button for access granted. The access granted action has you set what column to write the boolean to, so set that to the users table column you made.

This is the first lesson from the course I made on notifications, Quickly Set Up Push Notifications in Glide.


Thank you! I haven’t had a chance to watch the videos yet, but I’m guessing they will answer most of my questions!

Hi, I’m watching your videos now, and something that was throwing me off when I first tried setting up the column to track which users have allowed permissions is that I had initially watched this official Glide tutorial https://www.youtube.com/watch?v=OJNoy3hHx4w&t=63s that was showing how Glide has a specific column to add to the user table that is supposed to track if users have given push permissions.

I had tried adding it to my user table, and then I added the button “allow push notifications.” That button alone doesn’t seem to write anything to the user table. When I do the “check permission” button, Glide won’t allow me to choose the official Glide column that I created in the user table as the column that I want to write that data to.

I tried creating another non-specific boolean column to my user table, and Glide will allow me to choose that column to write the permission data to.

Do you know what’s going on with the official Glide boolean column that is supposedly built specifically to hold that data?

If I understand it right, the Glide column you mentioned automatically shows if the user has enabled notifications on their device. It’s a computed column and is not meant to be written to. It works on its own.

Ok, after doing a bit of testing, I think you’re right. I think my question now is, is there any purpose or need to have a button with the action, “push notification access granted” like @MatthewS has in his tutorial video? From looking around the community forum, I think the built-in access granted column option might be newer and maybe wasn’t available when he did his tutorial video?

There wasn’t a built in column when I did the tutorial, and I haven’t checked that out yet. Even before, there wasn’t a firm need for the access granted action. It was just helpful to have in guiding users to turn on notifications.

That’s what I figured. Great tutorials. Thank you for making them. I am working my way through them now.

You don’t mention it in the first video, but does the person need to be logged in as a user on the app in order for push notifications to work correctly? I was assuming yes because if not, wouldn’t there be no way for Glide to capture and “know” to send notifications to that person as there would be no user data, like the user email that you use in your test for sending the notification, right?

Apologies if you answer this in one of your later videos, but I was following along on the very first tutorial, and I did the steps to test the push notifications, and it all worked like it was seeming to in your video.

However, my question is, where did the notification go? It popped up on my screen for about one second, and then it was gone, and it wasn’t in my iPhone’s notification center. I also was assuming that I would get it as an actual email because I used user email as the contact, but I didn’t get an email either.

Do Glide notifications live somewhere on the app that users can go find them?

Yes, users do have to be signed in users (and can’t be using anonymous emails either unfortunately. That’s my biggest grief, waiting on glide to address.)

The notifications don’t exist anywhere in glide. You could make an action that saves them with an add row to a notifications table. I think I saw somewhere that glide may be building this in with a later update.

The notifications as they are, work like other apps. Perhaps it’s device dependent, but I’m used to them working where if you see it displayed on your screen while it’s unlocked, it’s considered viewed and then doesn’t show in your notification center. Just like if you tap the notification from your notification center, it disappears from there. Again though that’s just how your phone is handling it and has nothing to do with the guide app.

Sorry if I missed any of your questions or didn’t answer them fully… currently out and about and responding by email.

1 Like

Argh! I thought I had everything done correctly to allow users to enable push notifications! But what is happening is that push notifications don’t seem to want to work until the user closes out the app completely and then opens it again. Only then will the push notifications work, which is obviously a really bad user experience to ask them to do that in order for notifications to work. I’m not sure what I’m doing wrong!

I was trying to be fancy with the action flows of the push notification set-ups, so I thought maybe that was what my issue was. So I scrapped everything to go back to basics and exactly copied what you were doing in your setting up notifications tutorial, and I’m still running into the issue that after the user enables notifications, it won’t actually send them anything until they close and re-open the app.

Hello, I have the following issue. I am using the default column provided by Glide, “Push Notifications Access Granted.” However, when the column is created, it appears with the value “true” in all records (as seen in the image). Is this a column issue, or am I doing something wrong?

It’s a computed column based on if the current user approved notifications or not. It’s computed in real time for the current user only. It’s not a value that’s stored in the table.


According to Glide’s own example, they use that column to evaluate whether to display the notification settings screen to the user. If the column is set to TRUE, the screen should not be shown. However, since it’s always set to TRUE from the creation, I have no way to make the configuration screen appear for the first time. Once the user confirms, the configuration window shouldn’t be displayed again. How could I achieve something like this?

And that’s still the case. You probably approved notifications, so for you it’s going be true. If I’m using your app from my device, it’s probably going to be false.

Computed columns are evaluated on the user’s device. Not on Glide servers. So, the results will be different depending on the user and their specific device.

If you want to see it as ‘false’ to build your screens, you have 2 options:

  1. Change your condition until you are finished building that part of your app, and then change it back.
  2. Go into your browser settings, find the url for both your published app url and for glideapps.com and turn off the permission for notifications…or clear your browser cache, cookies, storage for those sites. Then the checkbox should be false.