ADF has five trigger types in 2021. Most teams use one -- the Schedule Trigger -- for everything. That's fine for simple workloads. It's suboptimal for workloads that would benefit from the other four. Here's the complete map of what each trigger type does and when it's the right tool.
Schedule Trigger
The trigger everyone uses. Runs a pipeline at specified times using a cron-like recurrence configuration. Daily at 2am, every hour, every 15 minutes, every Monday at 6pm. If your pipeline logic is "run at time X," this is your trigger.
{
"type": "ScheduleTrigger",
"typeProperties": {
"recurrence": {
"frequency": "Hour",
"interval": 1,
"startTime": "2021-01-01T00:00:00Z",
"timeZone": "UTC"
}
}
}
The limitation: Schedule Trigger doesn't know anything about time windows. It fires, runs your pipeline, and that's it. If your pipeline needs to know "what time window am I processing?", you have to pass that information explicitly through parameters -- and then you're responsible for tracking which windows have been processed.
When to use it: daily or periodic batch pipelines where the pipeline logic is time-agnostic, or where you're passing the time window parameters from your metadata configuration table.
Tumbling Window Trigger
This is the trigger most teams should be using more often than they do. It's also time-based, but it generates discrete, non-overlapping windows and passes the window start and end times to the pipeline as parameters. It also tracks state: which windows have been processed, which are still pending.
{
"type": "TumblingWindowTrigger",
"typeProperties": {
"frequency": "Hour",
"interval": 1,
"startTime": "2021-01-01T00:00:00Z",
"delay": "00:05:00",
"maxConcurrency": 50
}
}
The pipeline receives @trigger().outputs.windowStartTime and @trigger().outputs.windowEndTime. Your Copy Activity or Data Flow uses these to scope the extract.
The state tracking is the killer feature. If a window fails, ADF knows it failed -- the window stays in "failed" state. When you fix the underlying issue and rerun the trigger, it retries the failed windows before processing new ones. You don't need to build this tracking yourself.
Tumbling Window triggers also support dependencies between triggers: Trigger B fires for a window only after Trigger A has succeeded for the same window. This is powerful for pipelines that must run in sequence: raw extract must succeed before transformation can start.
When to use it: any pipeline where the logic is inherently time-windowed -- hourly partitioned writes, daily aggregations that reference a specific processing window, incremental loads where the watermark is a time boundary. If you're manually tracking watermarks for a Schedule Trigger pipeline, you probably want a Tumbling Window Trigger instead.
Storage Event Trigger (Blob Event Trigger)
Fires when a blob is created or deleted in an Azure Storage account. Internally, it subscribes to Azure Event Grid storage events. When the specified blob event occurs, ADF invokes your pipeline and passes the blob URL and related metadata.
{
"type": "BlobEventsTrigger",
"typeProperties": {
"blobPathBeginsWith": "/vendor-drops/landing/",
"blobPathEndsWith": ".csv",
"events": ["Microsoft.Storage.BlobCreated"]
}
}
When to use it: file-arrival-driven pipelines. Vendor drops a file to a storage account and ADF processes it immediately. This eliminates polling loops and processes files as soon as they arrive rather than at the next scheduled check.
Watch out for the file-writing timing issue: if a vendor uploads a large file in multiple chunks, Event Grid may fire before the file is fully written. Build a brief check at the start of your pipeline to verify the file is complete.
Custom Event Trigger
Fires on Azure Event Grid custom events from arbitrary sources -- not just Azure Storage. Any system that can publish to an Event Grid topic can trigger an ADF pipeline.
When to use it: event-driven integration across services where the source system can publish to Event Grid. An application that signals "new order batch ready for analytics processing" sends an Event Grid custom event which triggers the ADF pipeline. This is the pattern for near-real-time data pipeline triggering from application events without polling.
Schedule Trigger vs. Tumbling Window: The Common Mistake
The most frequent mistake I see is using Schedule Trigger when Tumbling Window is correct, then building manual watermark tracking to compensate.
Signs you've made this mistake: your pipeline reads a watermark from a SQL table at the start, runs the extract, updates the watermark at the end, and you have a separate monitoring job that checks whether windows have been missed. You've manually built the state management that Tumbling Window Trigger provides natively.
The fix: replace the Schedule Trigger with a Tumbling Window Trigger. Remove the manual watermark read and write from the pipeline. Use @trigger().outputs.windowStartTime and @trigger().outputs.windowEndTime directly. The trigger handles the state.
If you're choosing between trigger types for a new pipeline and aren't sure which fits, describe the pipeline logic to me. The right trigger type is usually obvious from the description. I'm here to help.