IFTTT Applet Trigger Configuration Missing a User-Configurable Bound for Large Upstream Datasets

Feature Scope

IFTTT Applets wire a trigger service to action services, and the platform polls the trigger on a server-side schedule rather than exposing a push endpoint or a user-set interval for most triggers. For triggers that expose large upstream datasets, the Applet editor offers no documented parameter to bound the scan window, limit result size, or pass an offset or cursor across runs.

Constraint Gap

Available controls are limited to selecting the trigger event, applying ingredient filters, and configuring action logic. Because the polling interval is not an Applet setting, a user cannot control how often a large dataset is scanned, nor can they walk the dataset page by page across separate runs. The Activity log records each run but functions as a review surface rather than a resumable cursor.

Open Question

Is there any documented or undocumented mechanism to constrain the volume of data a trigger evaluates per poll, or to resume a partial scan in a subsequent run, without relying on the upstream service to pre-filter results?

If not, what is the intended pattern for handling triggers that return thousands of records, given that the consumer Applet model does not expose database-style LIMIT/OFFSET semantics?

Do upstream services enforce their own result caps that IFTTT surfaces only indirectly through run behavior, and if so, where are those caps documented?

Verification Note

Polling intervals, run quotas, and log retention are platform behaviors that can change; treat any specific cadence or cap as unverified until observed in current Activity logs.