![How to choose the right idempotency key for an event: Keep the same idempotency key for retries of one action; use a new key for a new action.; Write: one [effect] for each [identity], e.g. one standard invoice per approved order.; Check stability, uniqueness, scope and lifetime; include tenant ID for tenant-scoped IDs. Choosing an idempotency key for an event](/covers/choosing-an-idempotency-key-for-an-event-640.webp?v=39704930)
Error Handling
Choosing an idempotency key for an event
Choose a stable idempotency key that recognises retries without blocking a legitimate new event or action.
Section
Error Handling
Error Handling
Comparing workflow versions before release
Compare workflow triggers, decisions, data, actions and recovery settings, including configuration outside a platform's version view.
Error Handling
Distinguishing repeated events from legitimate new actions
Tell redelivered events from genuinely new actions using both event identity and the identity of the business effect.
Error Handling
Expiring an approval request that receives no response
Set a business deadline, close an unanswered approval through a controlled transition and prevent late responses from authorising an action.
Error Handling
Handling API throttling with controlled retries
Handle API throttling with provider retry timing, shared pacing, bounded attempts and a clear failure route.
Error Handling
Handling deleted records during synchronisation
Set delete and restore rules for paired records, check actual deletion signals and prevent an unwanted record from reappearing.
Error Handling
Idempotency and duplicate prevention
Define idempotent workflow actions, stable keys and safe retry behaviour to prevent duplicate business effects.
Error Handling
Preventing duplicate invoices after a workflow retry
Protect invoice creation across workflow retries, lost responses and concurrent workers using a stable business identity.
Error Handling
Recording enough context to diagnose a failed workflow
Capture the IDs, attempted action, known outcome and safe error context needed to investigate a failed workflow.
Error Handling
Resolving conflicting updates from two systems
Identify competing record edits, choose a field-level rule and apply the resolution without overwriting another change.
Error Handling
Resuming a workflow after a service interruption
Use the last confirmed outcome and destination records to resume an interrupted workflow without blindly repeating work.
Error Handling
Rolling back a workflow without replaying completed actions
Redirect new workflow starts, classify affected outcomes and recover unfinished items without repeating confirmed external actions.
Error Handling
Rotating credentials without breaking scheduled workflows
Credential rotation succeeds when the old secret is revoked and every dependent workflow still runs as intended.
Error Handling
Routing failed records to an exception queue
Keep failed workflow records diagnosable and owned, then check retention, destination state and replay safety before recovery.
Error Handling
Safely retiring a workflow that other systems still use
Find a workflow’s remaining consumers, plan a cutover, settle pending and unknown work, and decommission it with an owner.
Error Handling
Separating retryable failures from invalid data
Decide whether a failed workflow record needs a bounded retry, data correction or reconciliation of an uncertain write.
Error Handling
Testing duplicate prevention before production
Test duplicate prevention with lost responses, concurrent delivery, changed inputs and legitimate new actions.
Error Handling
Validating transformed data before sending it onward
A workflow can transform a payload successfully and still send the wrong business value.
Error Handling
Workflow error handling
Classify workflow failures, limit safe retries, preserve unresolved records and confirm the destination outcome.