Please test: Glide Tables Zapier app ⚡️

We’re working on improving our Zapier integration. The first step is a revamped Zapier app for working with Glide tables!

  • Triggers: Row Added, Row Changed (requires Business plan to get all rows)
  • Actions: Add, Edit, and Delete Row.

For Triggers, you need to specify a date column, and the column must have a value in it.

Please give it a try, tell us how you use it, and share feedback.


Super excited about this! Game changer for how I use Glide in our business. Will be reporting back when I have enough Zap runs logged.

1 Like

This is awesome! Thank you for building such a great tool! I’m not as active in this community as I’d like to be but this is becoming such a valued part of my business and strategy.


Ya-hooo, fiery! It works, without a single line of code! It’s strange that rows from the table that have already been deleted are displayed for a long time (in the Zapier editor), updates do not help, but this is nothing! The ability to launch processes when rows appear in the Glide table is in itself very valuable, especially since we didn’t have to write any scripts. Hurray, let’s continue in the same spirit!


@David will you also be releasing a future update for


So there’s no Lookup/Search rows action? I’m not seeing how to edit (or delete) rows. Normally in Google sheets I would look up the row ID with a search step, then use that row ID in a later update step. How do I tell Zapier which row to edit?

They allow you to specify the rowID, so as long as you have a rowID from another step it should work.

Lookup/Search is not an action for Glide in Zapier as of now.

Yeah, that’s the question - how to get that Row ID. It’s not going to exist in any of the other apps I would use in a Zap, so I would need to search a different column with a value from a previous step.

What is your exact use case for that flow though?

Yeah, you will need to store the RowID somewhere if you are not trigger the action from inside of Glide.

Here’s what I’m currently doing with Google Sheets and Zapier. In our service business we use Quotient for quoting, Glide for managing jobs once they have been accepted, Quickbooks for invoicing and Zapier to connect them. I use both Google Sheets and Glide Tables as data sources in the same Glide apps. The most important Sheets are Jobs and Items (Job details).

Quotient allows quote writers to edit quotes, even after they have been accepted, then re-accept. When a quote is accepted, Zapier checks the Jobs sheet if the job is already there and either adds or edits accordingly, searching by Quote number. Same for Items, except that both edits and additions happen for each item. Items from a previous acceptance are marked inactive and new items are added.

Storing the Row IDs somewhere that Zapier can access them (Google Sheet) would defeat my goal of using only Glide Tables in Zapier. Although I suppose that additional Google Sheet wouldn’t have to be a data source for Glide. It just seems even more convoluted than what I already have!

One approach I’m considering is to have the Job ID be the Quote number combined with the timestamp of acceptance, instead of just the Quote number. Then Glide could determine that any jobs or items that aren’t the most current version of the quote can be ignored.

Let me know what you think!

Hmmm so what i want to do is lookup all rows that have a date older than 30 days ago and delete them…can i do that here? Not seeing how.

It’s correct that you don’t have to connect the helper Google Sheet to Glide, and you can add only two columns: the rowID, and whatever value you need to do the lookup on the Zapier side.

However, that means you have to keep two separate tables connected with all flows in the app, so when something happens on the Glide side, you must make adjustments as needed on the related row in Google Sheets. I don’t like that a lot for updates count.

You would need a way to get a list of rowIDs that match your condition, and run an iteration on that, I guess.

So, if you need to do that not with an action inside the app, you would have to get an API call first to query the related rows, and then iteratively delete those.

We’ve added a similar one for Make that you can try now:


I’m looking at upgrading to Business, mainly due to row count. Does the Zapier integration work the same way for Big Tables?

Should I wait until this moves beyond the Preview stage before relying on it for business-critical processes?