For a polling trigger, I don’t think you’re going to want to implement it this way. The way a Zap with a polling trigger works, is by saying “run this workflow, for every new item of data found in a result from my endpoint, from the moment the user turns the Zap on and after”. In other words, we’re not going back to the beginning of time and loading all data in your database. For a polling trigger, your endpoint should provide the items in reverse chronological order. When the Zap first turns on, we’ll take everything we see and populate a de-duplication database. We won’t process those items. On a subsequent poll, we’ll grab the most recent data your endpoint provides, compare it against the dedup database, and if we find previously unseen items we’ll use those to process through the Zap, and then add those to the dedupe database, so we know not to handle them again when we see them in subsequent requests. In other words, just provide the most recent objects from the last 15-30 minutes or so and we’ll do the rest. 

That said, in terms of your use case, the “let’s go back to the beginning of time and let the user choose to load everything” feature, stay tuned - we’re working on a mechanism to add this functionality in addition to today’s “from-this-point-on” event streaming way of automating workflows. 

Ok, thanks. Main idea was to do not load the database with heavy queries. When specifying the period, we receive a request much easier in terms of the load on our base.