Workflow production-readiness checklist

Use this checklist before activating a Workflow against a production Source. A successful editor save proves that the graph is structurally valid; it does not prove that provider permissions, real payloads, business conditions, or repeated side effects are safe.

1. Ownership and purpose

• Give the Workflow a unique, operational name and description.
• Record the owning team, business purpose, expected event volume, and response owner.
• Decide whether a direct Connection is simpler than a multi-Step Workflow.
• Keep production and test Workflows, Sources, and connected accounts visibly separate.
• Identify the current Workflow version used for the launch candidate.

2. Trigger and Source

• Confirm the exact Source, provider account, event definition, delivery mode, and resource filters.
• Prefer a named event over an “Any event” definition when the provider supports it.
• Send realistic examples for normal, missing-field, duplicate, and unexpected-event cases.
• Verify signature or authentication behavior for generic webhook Sources.
• Confirm that pausing or replacing the Workflow will not silently require historical events to be backfilled.

3. Authentication and access

• Confirm every account belongs to the intended FastHook team and provider environment.
• Check lifecycle state, current scopes, provider roles, app-installation resources, and object-level access.
• Open every remote picker and verify the selected channel, repository, sheet, drive, project, store, or record still exists.
• Separate sandbox/test and live credentials.
• Rotate exposed credentials before launch and keep secrets out of mappings, descriptions, fixtures, and screenshots.

Use Authentication and permissions for the reconnect and rotation procedure.

4. Data contracts and mappings

• Capture a real Trigger sample rather than relying only on a generic example.
• Verify every required Action input with missing and null source values.
• Confirm structured objects use JSON-aware mapping instead of accidental string interpolation.
• Check that every steps.<step-id> reference points to a topological ancestor on the same route.
• Revalidate downstream mappings after changing a Trigger, Transformation, Action operation, or Step order.
• Keep Audit previews’ 64 KiB and redaction behavior in mind when planning incident evidence.

5. Paths, Filters, and Transformations

• Test every custom Path with one matching event.
• Test the fallback with an event that matches no earlier Path.
• Confirm overlapping always/custom Paths are intentional when more than one route can run.
• Verify filtered or unmatched events produce the expected skipped Steps.
• Test JSON Patch against missing paths and arrays.
• Test JavaScript transformations with malformed, empty, and boundary input.
• Connect error routes where transformation or branch failures require an operational outcome.

6. Side effects and retries

• Identify which Actions create, charge, refund, send, publish, delete, or mutate provider state.
• Use provider idempotency keys or stable business identifiers where available.
• Do not assume a timeout means the provider made no change.
• Confirm HTTP 429, 5xx, and explicit retryable failures can repeat safely.
• Review the manifest rate limit and the provider’s own account-level quotas.
• Separate business-success notifications from technical recovery routes.
• Add compensating Actions only when they are themselves idempotent and observable.

FastHook allows up to 10 Workflow queue retries for retryable failures. See Limits, statuses, and error codes for exact behavior.

7. Delays and lifecycle changes

• Confirm Delay units and maximum duration; one configured Delay can span up to 30 days.
• Assume permissions, target resources, and business state can change during a long wait.
• Review queued and running executions before pausing, replacing, or deleting a Workflow.
• Avoid deleting a Workflow merely to stop new events; pause first when Audit history is still needed.

8. Audit and recovery

• Produce a controlled run and verify Trigger preview, version, Step order, mappings, outputs, statuses, and provider result.
• Force one safe validation failure and confirm the intended error route or terminal failure.
• Confirm operators can distinguish succeeded, failed, and skipped Step records.
• Record the first diagnostic location: Workflow Audit, cross-Workflow Activity, provider logs, or direct webhook event history.
• Keep a reviewed graph payload or maintained copy for recovery; historical versions are not a restore button.
• Define who may reconnect accounts, edit the graph, pause the Workflow, and repeat an Action.

9. Controlled activation

1. Pause the old Workflow or narrow the new Source when parallel side effects would be unsafe.
2. Save the final graph and record its version.
3. Activate the new Workflow.
4. Send one canary event with a recognizable business identifier.
5. Verify FastHook Audit and the final provider state.
6. Increase traffic gradually when the Source supports narrowing.
7. Watch the first production runs for permission, validation, rate-limit, and duplicate-side-effect failures.

10. Rollback procedure

If the launch is unsafe:

1. pause the Workflow to stop new runs;
2. inspect already queued, running, retrying, or delayed executions;
3. prevent repeated external side effects before retrying anything;
4. restore the known-good graph as a new version or reactivate the maintained previous Workflow;
5. run a controlled event; and
6. document affected request IDs, run IDs, provider object IDs, and compensating actions.

Do not delete incident evidence during recovery. Continue with Workflow versioning and migrations and Troubleshoot a failed run.