Scheduled automation in Salesforce, particularly Flows, can encounter unexpected failures due to Daylight Saving Time (DST) transitions. This issue commonly affects flows scheduled around 2 AM, leading to missed executions that can go unnoticed until downstream impacts arise.
Understanding the DST Impact on Scheduled Flows
Regions observing DST experience clock shifts twice a year:
- Spring Forward: Clocks jump from 1:59 AM directly to 3:00 AM, effectively skipping the 2 AM hour.
- Fall Back: Clocks revert from 1:59 AM to 1:00 AM, causing the 1 AM hour to repeat.
Scheduled Flows are configured to run at a specific time. When this specific time (like 2:00 AM) ceases to exist during the spring forward, the flow has no valid execution point and will not run. While the fall back might seem like it would cause a double execution, Salesforce internally handles scheduled jobs in GMT. The local clock adjustment means the job still runs once, but appears at a different local time before and after the transition. The spring skip, however, presents a genuine risk that GMT anchoring does not mitigate.
Unlike record-triggered flows that react to events, scheduled flows rely on precise chronological triggers. When the expected time vanishes or repeats, the trigger mechanism becomes unstable, leading to missed executions without platform-level errors because, from Salesforce's perspective, the scheduled moment simply didn't occur.
Workarounds for DST-Vulnerable Scheduled Flows
Several strategies can mitigate or resolve DST-related issues with scheduled flows:
1. Adjust Scheduled Time
The simplest approach is to avoid scheduling flows at 2 AM. Shifting the execution time to 1 AM or 3 AM ensures the hour exists unambiguously on both DST transition days. While 1 AM still carries a minor risk of double execution during the fall back, it eliminates the spring skip. For complete avoidance of both, schedule flows before 1 AM or after 3 AM.
2. Implement a DST-Aware Flow Trigger with Platform Events
For more complex requirements, consider an external scheduler that sends a Platform Event to Salesforce at the correct UTC time. A Platform Event-triggered flow within Salesforce can then listen for this event. Since the external scheduler operates in UTC, DST is irrelevant to its timing. This method keeps the logic declarative within Flow but adds complexity with additional components.
3. Design a Monitoring Flow
If scheduling at a DST-vulnerable time is unavoidable, implement a monitoring layer. Create a custom object (e.g., Flow_Health_Log__c) with a Last_Run__c datetime field. The scheduled flow should log a record and update this field upon successful execution. A separate flow, scheduled at a non-DST-vulnerable time, can then check if Last_Run__c is older than 25 hours. If so, an alert can be sent, notifying you of the missed execution and allowing for timely intervention.
4. Utilize Scheduled Apex
Scheduled Apex offers robust control over execution times by leveraging UTC internally. The System.schedule() method accepts a cron expression, which is evaluated against a fixed UTC anchor, thus bypassing DST complications.
Example:
String cronExp = '0 0 7 * * ?'; // 7 AM UTC daily
System.schedule('MyNightlyJob', cronExp, new MySchedulableClass());
The cron expression 0 0 7 * * ? translates to second 0, minute 0, hour 7, daily, every month, with day-of-week ignored. This ensures the job runs precisely at 7:00 AM UTC every day, regardless of local DST changes.
Cron expressions follow a six-field format: Seconds, Minutes, Hours, Day-of-Month, Month, Day-of-Week.
Example of a specific annual schedule:
// Fires once a year on February 10th at 8:30:20 AM UTC
String specificCronExp = '20 30 8 10 2 ?';
It's important to note that hourly automations in Salesforce do not adjust for DST; they operate on a different rule set than daily or higher-frequency schedules.
Key Takeaways
- Daylight Saving Time transitions can cause Salesforce Scheduled Flows to miss execution, particularly when scheduled around 2 AM during the spring forward.
- Salesforce handles scheduled jobs in GMT, mitigating some DST effects, but the spring skip remains a critical risk.
- Workarounds include adjusting the scheduled time, using Platform Events with external UTC schedulers, implementing monitoring flows, or migrating to Scheduled Apex for reliable UTC-based execution.
Leave a Comment