Thanks @harshil1712
Iām currently away from computer but know I do not have execute once (see screenshots).
Could it be anything to do with the fact theres nearly 8000 rows on that particular table? For instance, how does the trigger actually get fired? Does it wait for Airtable to say a modification has been made and does it know where that modification is or does it have to cycle through all 8000 records? Iām just trying to consider everything to get it to work.
It starts the workflow just one time with the 5 items.
Iām still not clear with this @RicardoE105. So if I have the airtable trigger poll on every 1 minute for example, what is actually happening? Is n8n looking at AirTable every 1 min of the day to identify if a modification to the airtable table has occurred? Or does it mean that when a modification takes place on the Airtable, the API sends notice to n8n as to what changes occurred from the very first instance of a change (at 0.001 secs for example) to when the last modification occurred at the final minute e.g from 0 secs to 1 min, what changes occurred?
What Iām getting at is depending on the answer presumably this could have a great bearing on the size of the table and how long it takes to cycle through to detect any changes? 
Is n8n looking at AirTable every 1 min of the day to identify if a modification to the airtable table has occurred?
This is correct. Just tested it and it works fine. I wonder if we are having a bug because of the number of records you are handling? 
Do you have time for a call? so you can walk me through what you are doing?
Thanks @RicardoE105. Thankfully I think I have now managed to get it to work. Your colleague @harshil1712 was in fact correct. When I got back to the office (just now), I checked the flow and indeed under the āSettingsā the Airtable trigger (and only this trigger) was on āExecute Onceā, and now Iāve seen 6 emails comes through of those 6 I selected. Many apologies for not noticing this sooner guys, I donāt even know how it got onā¦ I could kick myself but lesson learnt on my part.
@Jon thanks for you help aswell. I owe you one.
Ok, perfect. Glad you figured it out.
Since you were interested in the details, the filter below is applied behind the scenes to return the records that changed. We get 100 records at a time. Meaning that if 200 records changed, we make 2 HTTP requests.
qs.filterByFormula = IS_AFTER({${triggerField}}, DATETIME_PARSE("${startDate}", "YYYY-MM-DD HH:mm:ss"));
Brilliant thank you @RicardoE105. So presumably if on a large table such as mine I need to select say over 5000+ it might take a few seconds to run the flow?
@RicardoE105 quick questionā¦ this is working that well I think itās sending me email every 5 mins! Should I put an āExecute Onceā in the workflow and where would this be?
Sorry, I do not understand the question. Do you mean for testing? So you do not get that many emails until you are ready for āproductionā?
Itās okay @RicardoE105 I think I might know whatās happened.
Because the flow worked, I then renamed the flow (which was still active at the time), which I think then re-initiated the flow again (because renaming rebooted it), and then sent me another flurry of emails. I thought it was because it was re-iniating the flow every 5 mins (as per poll time, but this would incorrect).