Skip to main content

Get Support
Have a question? Let's get you an answer!

How Do I...? Troubleshooting Code & Webhooks Developer Zone

Other Help Resources
Wait, there's more! Check out these Community sourced spaces for additional resources.

Zapier Help Center Hire an Expert

Learning Resources
All of our best learning resources can be found here.

Featured Articles Show & Tell Zapier's products AI Hub Zapier Tools Hub

Share your knowledge
Give back to the Community by sharing your automation wins and helping to answer questions.

Share your success See unanswered questions User Groups

Other Learning Resources
Some of our favorite additional ways to upskill your Zapier knowledge.

Zapier Learn Zapier Blog Zapier Webinars

Product Updates
Check out what is new and upcoming with Zapier with our regular product updates.

Product Updates

Early Access Program
Want to join Early Access? Learn more here.

I am new to Zapier. I have a trigger that runs the “New Document Within a Firestore Collection” event. I want this trigger to capture the entire document for data to be used in downstream tasks. But I am confused by the query field in the trigger tab. I don’t want the new document in firestore to query a trigger for documents, I want the new document itself as a payload (or at least the document id). This is what I have so far:

This will work in theory because when a new doc is created and the event is triggered, the most recent created_at will be the doc in question. But what if a 2nd user creates a new document in the time of the Zapier trigger to when this query runs? Having to re-query the firestore collection when we already have the new document trigger seems unnecessary and potentially unsafe for data consistency.

 

How can I get the new document (or its id to then use with a where filter query) directly out of the trigger so I don’t have to rely on a created_at sort?

Hi @big_dag_guy, welcome to the Community! 🎉 

As the orderBy property is required so that new documents can be sorted in the correct order I’d have thought it would be best to use a timestamp type of field rather than an ID for that.

The New Document Within a Firestore Collection trigger is a polling type of trigger so it would check for new documents at regular intervals to see if there’s a new document with an ID that it hasn’t seen before. If a new document was added just after the query was run and was missed, then it should be seen the next time the Zap runs the query again which should then trigger the Zap for that document. Also want to note that the limit property is assigned automatically so that can be removed from the Query field.

Hope that helps to clarify things here. If you have further questions or there’s anything else I can assist with please let me know! 🙂

Got it, thank you. So if I’m reading the linked docs correctly, lets say that users create 5 new documents in between polls. Zapier will poll Firestore and find 5 docs it has not processed yet. Then process them and add to the “processed ids” field. And repeat. And my query should look like this:
"orderBy": [{ "field": { "fieldPath": "created_at" }, "direction": "DESCENDING" }]

That’s correct, @big_dag_guy. 🙂 

So if I’m reading the linked docs correctly, lets say that users create 5 new documents in between polls. Zapier will poll Firestore and find 5 docs it has not processed yet. Then process them and add to the “processed ids” field. 

Yes, when the Zap next polls Firebase/Firestore looking for new information it will find any new documents it’s not yet triggered on and then the Zap will run for each new document individually. 
 

And my query should look like this:
"orderBy": [{ "field": { "fieldPath": "created_at" }, "direction": "DESCENDING" }]

Yes, that query looks all good to me! 🙌

Do let me know if there’s anything further I can help with on this, keen to ensure you’re all set here.

Terms & ConditionsAccessibility statement