SfSkills Domains Docs GitHub

Home / flow / flow-time-based-patterns

flow-time-based-patterns

Time-based execution in Salesforce Flow — Scheduled Paths in record-triggered flows (delays measured against a record date or trigger fire time), the Wait element in autolaunched / orchestration flows, scheduled flows on a cron-like cadence, the offset semantics (`+N` days vs `-N` days from a date field), requeueing when the source record changes, the time-zone rules that decide when 'tomorrow at 9 AM' actually fires, and the workflow-rule-time-based-action replacement playbook.

Open the skill folder on GitHub

Flow Time-Based Patterns

Time-based logic in Flow has three distinct mechanisms, each with different runtime semantics, governor scope, and time-zone behavior. Confusing them — using a Wait element in a scheduled flow, or expecting a Scheduled Path to re-evaluate when the source record changes — produces some of the most confused-debug Flow incidents.

What this skill is NOT. The basic Flow elements (Decision, Loop, Get / Create / Update Records) work the same way regardless of time-based wrappers — go to Salesforce help. Apex's System.scheduleBatch and Schedulable interface live in a different runtime — see apex/scheduled-apex. The classic Workflow Rule time-based-action migration story is covered here as one specific pattern, not the topic of the whole skill.

Before Starting

Core Concepts

The three time-based mechanisms

MechanismWhere it firesTriggerTime-zone basis
Scheduled Path in a record-triggered flowAsync, after the record-trigger firesRecord save matching the trigger criteria + a configurable delayRunning user (the user who saved the record)
Scheduled FlowAsync, on a cron expressionCron schedule (org-defined) — daily, weekly, hourly, etc.Org default
Wait ElementPauses an autolaunched / orchestration flow interviewConfigurable resume condition (absolute time, duration, platform event)Depends on the resume-condition specification

A record-triggered flow can have BOTH an immediate path and one or more Scheduled Paths off the same trigger. A Wait element doesn't exist in record-triggered flows — only autolaunched and orchestration.

Scheduled Path offset semantics

A Scheduled Path runs at: base date + offset. The base date can be:

Negative-offset paths against a date field that's already in the past fire immediately (the platform considers the scheduled time already past).

Re-evaluation on update: the most-misunderstood feature

Default behavior: a Scheduled Path that was queued at trigger fire time stays queued. If the triggering record is updated to no longer meet the entry criteria, the Path still fires unless re-evaluation is configured.

Configuring re-evaluation: the Scheduled Path's "Recheck the entry condition" toggle. When enabled, the platform re-evaluates the record's state against the entry criteria at the moment the Path runs. If the criteria no longer matches, the Path silently exits.

This matters for "send a reminder 2 days before SLA expiration" — if the case is closed before the reminder fires, recheck-on-execution prevents sending an irrelevant reminder.

Time zone: the silent landmine

MechanismTime zone resolves as
Scheduled Path "+N days at 9 AM"The running user's time zone — the user who saved the record
Scheduled Flow on a cron scheduleThe org default time zone
Wait element in a screen flowThe user's session time zone (often same as running user, but not guaranteed)
DateTime literal in a Decision elementUTC unless explicitly converted

A Scheduled Path on a global team's record-triggered flow fires at 9 AM in each user's time zone — meaning records saved in EMEA fire at 9 AM London, records saved in APAC fire at 9 AM Tokyo. For some workflows that's correct (regional reminders); for others (e.g. a global SLA cutoff) it's wrong.

The fix: store the desired fire time in UTC on a record field and use field-based offset, OR move the logic to a Scheduled Flow that uses the org default.

Common Patterns

Pattern A — Send a reminder before a date field

When to use. "Email the case owner 2 days before Case.SLA_Expiration_Time__c — but only if the case is still open."

Implementation.

The reminder body uses Action: Send Email Action. Standard fault path on the email send (see flow/flow-error-notification-patterns).

Pattern B — Cancel-and-reschedule on field change

When to use. SLA expiration changed by an admin or escalation process — the original Scheduled Path should be cancelled and a new one queued from the new date.

Implementation. Salesforce does not expose direct cancel/reschedule of an already-queued Scheduled Path. Workaround:

The actually-firing Path checks state at execution time and silently exits if the world has changed.

Pattern C — Scheduled Flow for periodic batch work

When to use. "Every weekday at 6 AM, find all open cases with SLA breach risk and email the owners."

Implementation.

Scheduled Flows have a per-execution governor scope independent of the record-triggered flow that might also touch the same records. Don't try to do per-record work that should have been a Scheduled Path on the record-triggered flow.

Pattern D — Wait element for in-flow pause

When to use. Autolaunched flow that needs to pause until a specific time or until a Platform Event fires.

[Get Records: pull tasks]
    │
    ▼
[Wait: until Platform Event 'Approval_Decision__e' OR 24 hours]
    │
    ├── on event resume → process approval
    │
    └── on timeout → escalate

Wait elements support:

Constraint. Wait elements are only available in autolaunched and orchestration flows. They cannot exist in record-triggered or screen flows.

Pattern E — Workflow-rule time-based-action migration

When to use. Migrating a classic Workflow Rule with a time-based action (e.g. "if SLA breached, escalate after 4 hours") to Flow. Salesforce has been deprecating Workflow Rules; this pattern is common.

Mapping.

Workflow Rule conceptFlow equivalent
Rule triggerRecord-triggered flow's start
Rule criteriaFlow's entry criteria
Time-based queueScheduled Path
Re-evaluation ruleRecheck entry condition on the Path
Workflow action (field update / email / outbound msg)Flow Action: Update Records / Send Email / Action

Common mistake: the workflow rule's "evaluate when records are created and any time they're edited" maps to record-triggered flow's Run when a record is created or updated. Forgetting this leaves the new flow firing only on create.

Decision Guidance

SituationApproachReason
"Run X 2 days after this case is created"Scheduled Path on record-triggered flow, +2 days from trigger fireStandard pattern
"Run X 2 days BEFORE this case's SLA"Scheduled Path with -2 days from SLA field, recheck enabledNegative offset against record date field
"Run X every weekday at 6 AM"Scheduled Flow with cron expressionNo record trigger; cron-driven
"Pause until approval comes in"Wait element in autolaunched flow with Platform Event resumeInteractive wait
"User saved a record but I want the path to fire at the org's 9 AM not the user's"Move the work to a Scheduled FlowScheduled Paths use running-user TZ
"If the record changes after queueing, cancel the path"Recheck entry condition on the Scheduled PathDefault is no recheck; explicit toggle
Migrating a classic Workflow Rule with time-based actionsPattern E mappingStandard migration playbook
"My Wait element doesn't appear in my record-triggered flow"You can't add Wait there — use Scheduled PathWait is autolaunched / orchestration only
"Negative offset against a past date"Path fires immediatelyPast scheduled times execute immediately
  1. Pick the mechanism. Scheduled Path / Scheduled Flow / Wait — not interchangeable.
  2. Decide the base time and offset. Trigger fire time vs record date field vs cron expression.
  3. Resolve the time zone explicitly. Running user, org default, or UTC. Document the choice.
  4. Decide re-evaluation behavior. For Scheduled Paths: "Recheck entry conditions" toggle. Default off; almost always you want it on.
  5. Build it. Standard Flow Builder.
  6. Test the time-zone case. Save a record as a user in a different time zone. Confirm the Path fires at the expected absolute time.
  7. Test the recheck case. Update the source record between queue and execution; confirm recheck behavior.

Review Checklist

Salesforce-Specific Gotchas

  1. Scheduled Path uses the running user's time zone, not the org's. A "9 AM" path means 9 AM in EACH saving user's local time. (See references/gotchas.md § 1.)
  2. Scheduled Path with negative offset against a past date fires immediately. "2 days before Aug 1" against a case saved on Aug 5 fires now, not nothing. (See references/gotchas.md § 2.)
  3. Recheck entry condition is OFF by default. A queued Scheduled Path fires even if the source record no longer meets the entry criteria. (See references/gotchas.md § 3.)
  4. Wait elements are NOT available in record-triggered flows. They're autolaunched / orchestration only. (See references/gotchas.md § 4.)
  5. Scheduled Flows use the org-default time zone, not the configurer's. "Daily at 6 AM" means 6 AM in the org's TZ, regardless of who set up the flow. (See references/gotchas.md § 5.)
  6. Cancelled / deleted source record while a Scheduled Path is queued — the Path still fires; recheck condition that includes IsDeleted handles deleted records. (See references/gotchas.md § 6.)
  7. Migrating Workflow Rule "evaluate every time a record is edited" maps to Flow's Run when a record is created or updated, not just create. (See references/gotchas.md § 7.)

Output Artifacts

ArtifactDescription
Time-based mechanism choiceScheduled Path / Scheduled Flow / Wait, with rationale
Offset configurationBase time + signed offset (e.g. -2 days from SLA_Expiration_Time__c)
Time-zone documentationWhich TZ resolves the schedule, and why that's correct for the requirement
Recheck-entry-condition decisionOn / off, with explanation of what changes between queue and execution
Test matrixTime-zone edge case + recheck edge case + negative-offset edge case

Package files