Scheduled automation in Salesforce, Flows in particular, can fail unexpectedly when Daylight Saving Time shifts the clock. Flows scheduled around 2 AM are the usual casualty, and the miss often goes unnoticed until something downstream breaks.
How DST affects scheduled flows
In regions that observe DST, the clock shifts twice a year:
- Spring forward: the clock jumps from 1:59 AM straight to 3:00 AM, so the 2 AM hour never happens.
- Fall back: the clock goes from 1:59 AM back to 1:00 AM, so the 1 AM hour repeats.
A Scheduled Flow is configured to run at a specific time. When that time (2:00 AM, say) ceases to exist during the spring forward, the flow has no valid execution point and does not run. Fall back looks like it should cause a double execution, but Salesforce handles scheduled jobs in GMT: the job still runs once, it just appears at a different local time before and after the transition. The spring skip is the genuine risk, and GMT anchoring does not mitigate it.
Record-triggered flows react to events. Scheduled flows depend on a precise chronological trigger, so when the expected time vanishes or repeats, the trigger becomes unstable and the run is missed with no platform-level error, because as far as Salesforce is concerned the scheduled moment simply did not occur.
Workarounds for DST-vulnerable scheduled flows
Several strategies can reduce or remove the risk.
1. Adjust the scheduled time
The simplest approach is not to schedule flows at 2 AM. Move the run to 1 AM or 3 AM and the hour exists unambiguously on both transition days. 1 AM still carries a minor risk of double execution during the fall back, but it eliminates the spring skip. To avoid both, schedule before 1 AM or after 3 AM.
2. Build a DST-aware trigger on platform events
For more complex requirements, have an external scheduler send a Platform Event to Salesforce at the correct UTC time, and let a Platform Event-triggered flow listen for it. The external scheduler works in UTC, so DST never enters into its timing. The logic stays declarative inside Flow, at the cost of more moving parts.
3. Design a monitoring flow
If scheduling at a DST-vulnerable time is unavoidable, add a monitoring layer. Create a custom object such as Flow_Health_Log__c with a Last_Run__c datetime field, and have the scheduled flow log a record and stamp that field on every successful run. A separate flow, scheduled at a time DST cannot touch, then checks whether Last_Run__c is older than 25 hours and alerts you if it is, so you hear about the missed run while you can still do something about it.
4. Use scheduled Apex
Scheduled Apex gives you tighter control over execution times because it works in UTC internally. System.schedule() takes a cron expression evaluated against a fixed UTC anchor, which sidesteps DST entirely.
An example:
String cronExp = '0 0 7 * * ?'; // 7 AM UTC daily
System.schedule('MyNightlyJob', cronExp, new MySchedulableClass());
The cron expression 0 0 7 * * ? reads as second 0, minute 0, hour 7, daily, every month, day-of-week ignored. The job runs at 7:00 AM UTC every day whatever the local clock does.
Cron expressions use six fields: seconds, minutes, hours, day-of-month, month, day-of-week. A specific annual schedule looks like this:
// Fires once a year on February 10th at 8:30:20 AM UTC
String specificCronExp = '20 30 8 10 2 ?';
A catch worth knowing: hourly automations in Salesforce do not adjust for DST at all. They run on a different rule set from daily or higher-frequency schedules.
Leave a Comment