SQL Server Polling Trigger Skips Records When Updates Occur During Processing

[Patel0786]

We are facing an issue with the SQL Server 5-minute interval polling trigger recipe.
The trigger recipe is already in Started state.
 When we update a record in SQL Server, the job is picked up after some time and starts processing, which is expected.
However, during this processing time, if we update another record (without refreshing the recipe and without clicking Check for jobs), that second update is getting skipped.
After waiting for the next 5-minute polling interval, we observed the following message:

"Last checked at Jan 13, 2026, 4:21:59 AM PST Found 1 job, queued it for processing. Skipped 1. Current queue size: Approx. 1 job Estimated time to clear queue: less than a minute"

Only one record/job gets processed, while the record updated during the ongoing processing is skipped.
Expected Behavior:
 All records updated in SQL Server should be captured and queued for processing by the polling trigger, even if they are updated while another job is already being processed.
No record should be skipped as long as it meets the trigger conditions.
Actual Behavior:
 When multiple records are updated within the same polling window and one is already under processing, the subsequent update is skipped.

[francbaviello]

Hi @Patel0786, Workato assumes that if a job is already being processed, it won’t enqueue new jobs that were updated in the same polling window. this limitation exists because: polling triggers are not real-time, queue size control and the “last checked at” timestamp is updated once a poll finishes or when the first job is queued.

Possible workaround:

1. Reduce poll interval: Lower the polling interval (e.g., 1 minute) to reduce the likelihood of updates happening during processing (Warning: higher frequency increases load on SQL Server and Workato).
2. Use WHERE conditions on an UpdatedAt column Ensure your trigger uses a reliable column like LastModified timestamp. Example: SELECT * FROM MyTable WHERE LastModified > :last_checked ORDER BY LastModified ASC
   This ensures all updates since the last poll are captured.
3. Use a “staging table” approach: Instead of relying on last checked timestamps, maintain a queue table in SQL Server:
   Every updated record is inserted into this table. The trigger polls this table. After processing, the row is marked as processed. This guarantees no record is ever skipped, independent of processing time.

[RussellJ]

Just bumped into this post and your reply @francbaviello (thank you for taking the time to respond and in such detail - appreciated!).  But I must have misunderstood your response (and in the same way I think as per @Patel0786 and their original query).  So just wanted to clarify how the polling mechanism works in Workato...

I've been involved in designing polling systems before and the way they work is to keep a "high water mark" of the last record in the table/queue that was successfully processed.

• So, when the first poling interval arrives, we see 3 new records (id 1-3).  We grab all three records (or one at a time) and process them.
• Then we store the last id processed (3) - this is our "high water mark" for this table.
• The next time the polling interval arrives, we use the "high water mark" value (3) when determining which records are "new" and therefore need processing. In a simple SQL scenario we'd just say WHERE id > high_water_mark.

This mechanism ensures no records are missed.

I would have expected Workato to work in the same way, however from your explanation it seems (alarmingly) not to.  Instead I think you're suggesting the following...

• The polling interval arrives, lets say 9:00 AM.  Workato grabs the records waiting (id 1-3) and processes them.  Let's say this takes a minute so the job finished at 9:01 AM.  During this minute of processing, let's say, two new records arrive (id 4-5).
• Workato then sets the current time (i.e. when it finished processing @ 9:01 AM - one minute after the START of the first polling run) as a "high water mark" timestamp.
• The next time the polling interval arrives, Workato use the "high water mark" value (9:01 AM) when determining which records are "new" and therefore need processing. In a simple pseudo-SQL scenario we'd just say WHERE timestamp > 9:01 AM.

Clearly in this case, we're going to miss records 4&5 that were created during the one minute processing window.  This surely cannot be how polling works in Workato?

I could understand that Workato might use a timestamp as a "high water mark" but surely the pseudo-SQL would then be  WHERE timestamp > 9:00 AM?  In other words, the time of the START of the last polling interval (not when processing finished)?

Otherwise you're going to miss any record created (and/or updated) during any job run.  The chances of this happening will increase with Recipe duration, but even a very quick Recipe still leaves this as a possibility.

Keen to get a definitive answer on this, as otherwise it feels like a fundamental issue as to how polling works.

[RussellJ]

@gary1 any thoughts? 😀

[gary1]

I think only Workato can answer this, or whoever developed the SQL connector. It could be a faulty closure on the trigger. Hard to say without seeing the code.