Production Rollout Checklist

Use this checklist when moving a real workflow from inline backend code into Causet. It complements the Retrofit an Existing App guide.

Choose one workflow

• Start with one endpoint, webhook, cron job, queue worker, or agent action
• Avoid critical-path migrations first — pick a flow with retry/visibility pain, not your highest-risk payment path on day one
• Confirm the flow has multiple steps that can partially fail, or needs audit/replay visibility
• Read When Not to Use Causet — skip flows where simple CRUD is enough

Define ownership

• Document what remains synchronous in the API route (validation, auth, immediate response)
• Document what moves to Causet (downstream steps, retries, state transitions)
• Decide which database writes remain in the app vs which are recorded as Causet events/projections
• List the state transitions Causet will own on the timeline
• Review What Causet handles vs what stays in your app

Add correlation IDs

Pass stable IDs so webhooks and follow-up intents can find the right workflow instance:

• entityId — primary entity for the stream (e.g. leadId, orderId, userId)
• workflowId / executionId — if using true async mode with status polling
• Provider event ID — Stripe evt_…, CRM event ID, DocuSign envelope ID
• Business IDs — userId, orderId, leadId, importJobId

See Correlation and Causation and Use Webhooks to Update Existing Flows.

Make side effects idempotent

Webhook providers and queues deliver at-least-once. Side effects must survive duplicates:

• Email sends — dedupe by intent idempotency key or provider message ID
• Payment updates — idempotent by payment intent / charge ID
• CRM sync — upsert by external record ID
• Notifications — check-before-send or idempotent channel APIs
• Webhook processing — use provider event ID as idempotency key

Handle failures

• Define retry policy per side effect (which failures retry, backoff, max attempts)
• Define dead-letter or human-review path when retries exhaust
• Document repair/replay process — who can fork, who approves corrections
• Decide behavior when Causet runtime is unavailable (fail closed vs buffer vs fallback)

Observe timelines

• Confirm the happy path appears correctly in the timeline (causet inspect timeline or Debugging Timeline)
• Simulate provider failure — verify failed step is visible and retry is scheduled
• Simulate duplicate webhook — verify idempotency rejects or no-ops the second delivery
• Confirm the timeline is understandable by someone who did not write the handler

Roll out safely

• Use feature flags if available — route a percentage of traffic through the Causet path
• Shadow the existing flow if possible — submit intents without changing user-visible behavior
• Start with internal or test traffic before production users
• Roll out to a small percentage, then expand
• Document rollback plan — how to revert to the inline handler if needed

Next steps

• Retrofit an Existing App
• Use Webhooks to Update Existing Flows
• Add Causet to Next.js
• Run Causet with a Local App — what works locally today