Cancel run later

Overview

Cancel run later deletes a previously scheduled event by its unique key. Use this stage to prevent a scheduled task from running after it's been queued with Run later.

Where to find it: Flow Control in the stage library.

Configuration

Required Fields

Using functions in these fields: Any value field above accepts @ functions, for example @NowSecond for the current time or @calc(...) for a calculation. 

See Flows Functions for the full list.

Exit Points

How It Works

When executed, the stage:

1. Resolves Timer ID - Evaluates the schedule ID variable from flow
2. Appends operator ID - Constructs full key with operator isolation
3. Deletes schedule - Removes scheduled event from queue
4. Returns success - Always routes to Pass (even if nothing was deleted)

Key behavior: Always succeeds even if schedule not found - idempotent operation.

Common Use Cases

1. Order Cancellation with Schedule Cleanup

Cancel order and prevent scheduled processing.

• Update database: Mark order cancelled
• Cancel run later: {{orderTimerId}} (must match the exact Timer ID used when the schedule was created with Run later)
• Add To Response: orderStatus → cancelled
• Return true

Result: Order cancelled + scheduled processing prevented.

2. Conditional Cancellation

Only cancel if status indicates cancellation.

• Route Flow: {{status}} Equal cancelled
  • Pass:
    • Cancel run later: {{myTimerKey}}
    • Return true
  • Fail: Return true (no cancellation needed)

Result: Only cancel if status is marked cancelled.

3. Retry Schedule Cleanup

Cancel future retries if current attempt succeeds.

• Call API: {{endpoint}} (retry attempt)
• Route Flow: {{success}} Equal true
  • Pass:
    • Cancel run later: {{retryTimerId}} (must match the exact Timer ID used when the retry schedule was created)
    • Return true
  • Fail: Return false (retry will happen as scheduled)

Result: Cancel future retries if current attempt succeeds.

4. Batch Schedule Cancellation

Bulk cancel multiple pending schedules.

• Query data: Fetch cancelled_orders where cancel_requested = true
• Loop: Iterate over {{cancelled_orders}}
  • Cancel run later: {{current.timerId}} (the Timer ID you stored on each record when scheduling)
  • Mark processed in database

Result: Bulk cancel multiple pending schedules.

Key Behaviors

Timer ID Management

Important: Run later does not create an automatic Timer ID variable. You choose the Timer ID value yourself when you set up Run later, and you must reuse that exact same value here to cancel the schedule. Store your own key (in the flow or in storage) so you can reference it later.

Example Flow:

• Run later: Timer ID = orderReminder_{{orderId}} (a value you define)
• Save Data: Store that same key (e.g. as myTimerKey) with the order
• Later, to cancel:
  • Fetch Data: Retrieve myTimerKey from storage
  • Cancel run later: {{myTimerKey}} (must exactly match the Run later Timer ID)

Best Practices

• ✓ Store Timer ID when creating schedule (save to database or storage)
• ✓ Reuse the exact Timer ID value you set on Run later (store it yourself, e.g. {{myTimerKey}})
• ✓ Verify Timer ID exists before attempting cancellation
• ✓ Use in cancellation flows to prevent pending executions
• ✓ Test that scheduled event actually cancels before expected execution time
• ✓ Clean up schedules when associated workflows are cancelled

Common Mistakes

Troubleshooting

Do's and Don'ts

Do:

• ✓ Reuse the exact Timer ID value you set on Run later
• ✓ Store Timer ID when creating schedule
• ✓ Verify Timer ID exists before cancellation
• ✓ Test cancellation in staging environment
• ✓ Clean up schedules in cancellation flows

Don't:

• ✗ Use arbitrary IDs (must match actual schedule)
• ✗ Expect failure exit if schedule not found
• ✗ Assume cancellation is immediate (may take time)
• ✗ Leave schedules orphaned unnecessarily

Edge Cases

• Timer ID not found: Stage still succeeds (no error returned).
• Already cancelled: Stage still succeeds (already deleted).
• Null/empty Timer ID: May cause error during deletion (logged but stage succeeds).
• Race condition: If cancellation runs simultaneously with schedule execution, outcome is unpredictable.
• Multiple calls: Can call multiple times safely - idempotent operation.

Related Stages

• Run later: Creates the scheduled event that this stage cancels
• Save Data: Store Timer ID for later cancellation
• Fetch Data: Retrieve Timer ID when ready to cancel
• Route Flow: Add conditional logic before cancellation