In Azure Data Factory (ADF), triggers are the engines that bring your pipelines to life. They automate execution based on schedules, events, or time windows – eliminating manual intervention and making data workflows truly “set and forget”.
ADF supports three trigger types, each designed for different automation scenarios
1. Schedule Trigger: The Timekeeper
The Schedule Trigger runs pipelines on a clock-based schedule -hourly, daily, weekly, or using advanced calendar options like “every Monday at 5 PM and Thursday at 9 PM”.
Use Cases:
- Daily ETL jobs at midnight
- Hourly data ingestion from source systems
- Weekly report generation
Pro Tip: Schedule triggers follow a “fire-and-forget” pattern – they mark execution as successful as soon as the pipeline starts, regardless of completion
2. Tumbling Window Trigger: The Stateful Schedule
A Tumbling window trigger is designed to process data in clearly defined chunks of time, where each chunk (or “window”) has a fixed duration and does not overlap with others. You can think of time being divided into back-to-back segments – like 1-hour blocks, 10-minute blocks, or even daily intervals-and each segment is handled exactly once.
For example, if you set a tumbling window of 1 hour, the system will process data from 10:00–11:00, then 11:00-12:00, then 12:00-13:00, and so on. These windows are consecutive and non-overlapping, meaning no data is processed twice and no time period is skipped.
One of the key strengths of a tumbling window trigger is that it maintains state. This means it keeps track of which time windows have already been processed and which are pending. Because of this, it ensures exactly one execution per window, even if there are failures or delays. If something goes wrong during processing, the system can retry that specific window without affecting others.
This makes tumbling window triggers especially useful for:
- Processing time-based data pipelines (like hourly logs or daily reports)
- Ensuring consistent, reliable data processing
- Handling scenarios where missing or duplicate processing would cause problems
In contrast to simple schedule-based triggers (which just run at certain times without tracking what has already been processed), tumbling window triggers are more reliable and structured because they are aware of time intervals and their processing status.
In short, a tumbling window trigger gives you a dependable way to process data in strict, sequential time blocks-ensuring completeness, consistency, and no duplication.
Key Differences from Schedule Triggers:
| Feature | Tumbling Window | Schedule Trigger |
| Backfill Support | Yes (past windows) | No |
| Reliability | 100% (no skipped windows) | Lower |
| Retry on Failure | Built-in retries | No |
| Concurrency Control | 1-50 concurrent runs | No |
Use Cases:
- Hourly batch processing of sensor data
- Daily sales aggregation (must run for every day, no skips)
- Rolling window calculations
Real Example with WindowStart/WindowEnd:
System Variables Available:
- @trigger().outputs.windowStartTime – Window start
- @trigger().outputs.windowEndTime – Window end
These allow your pipeline to process exactly the data for each time slice
3. Event-Based Trigger: The Reactor
Event-Based Triggers respond to events in Azure Blob Storage – typically file creation or deletion.
Use Cases:
- Ingest files as soon as they land in a data lake
- Trigger transformation after raw data upload
- Automated workflows based on data arrival events
Configuration Example (UI):
- Trigger Type: Storage Event
- Event: Blob Created
- Container: /incoming-data
- Blob path begins with: /sales/2025/
- Blob path ends with: .csv
Important Considerations:
- Requires Event Grid enabled on storage account
- Supports only Azure Blob Storage Gen2 and GPv2 accounts
- Maximum 500 triggers per storage account
- Use @triggerBody().folderPath and @triggerBody().fileName to capture file details in your pipeline
Practical: Real-World Incremental Load Pipeline
Here’s how you’d combine a Schedule Trigger with an incremental load pattern (watermarking)
Schedule Trigger (Daily at 12:00 AM IST)
pipeline: IncrementalLoad_Customers_Daily
- Lookup Activity — Get last load timestamp from WatermarkTable
- Copy Activity — WHERE LastModifiedDate > LastLoadDate
3. Stored Procedure — Update watermark to current timestamp
Code for Lookup Query:
SELECT LastLoadDate FROM WatermarkTable WHERE TableName = ‘Customers’
Dynamic Copy Query:
SELECT * FROM Customers WHERE LastModifiedDate > ‘@{activity(‘LookupLastLoad’).output.firstRow.LastLoadDate}’
This ensures only new or updated records are processed daily — optimizing performance and cost
Quick Summary Table
| Trigger Type | Best For | Pipeline Relationship |
| Schedule | Time-based recurring jobs | Many-to-many |
| Tumbling Window | Exactly-once, non-overlapping time slices | One-to-one |
| Event-Based | File arrival/deletion events | Many-to-many |
Final Takeaway
Start with Schedule Triggers for simple time-based automation. Use Tumbling Window when you need reliability and backfill support for time-series data. Adopt Event-Based triggers for real-time responsiveness to file arrivals. Master all three, and you’ll build robust, automated ETL pipelines that run themselves.
