Workflow release and rollback checklist

Use this checklist after a Workflow has passed functional testing and before it handles production events. It complements the broader production-readiness checklist with an environment cutover, canary, rollback, and evidence procedure.

Release record

Open one release record and assign:

• release ID, owner, approver, start time, and observation window;
• destination team ID, Workflow ID, Source ID, and pre-release Workflow version;
• reviewed source Workflow ID and version when configuration was promoted;
• provider tenant and connected-account identity for every Action;
• change summary, expected business outcome, and acceptable error/latency threshold;
• dashboards, alert receivers, reconciliation query, and incident channel; and
• rollback owner, rollback payload or known-good Draft, and stop conditions.

Use identifiers and hashes where possible. Do not paste secrets, raw Trigger payloads, complete Step outputs, or provider tokens into the release record.

Preflight gate

• [ ] The production Source belongs to the intended team and provider account.
• [ ] Every reusable Destination, Filter, and Transformation ID was remapped for production.
• [ ] Every Action uses the intended production connected account and least-privilege permissions.
• [ ] Required mapping fields, Paths, fallback behavior, error routes, retries, idempotency, and Delays were reviewed.
• [ ] Test data cannot create an unintended production side effect.
• [ ] The production Workflow remains draft, paused, or otherwise unable to process live events during validation.
• [ ] The current graph and integer version were retrieved immediately before the release.
• [ ] Monitoring covers failed runs, Trigger channel state, active alerts, result-window overflow, and the business outcome.
• [ ] The on-call owner can pause the Workflow or upstream sender without waiting for the release author.
• [ ] The rollback procedure has been reviewed and does not depend on a one-click historical restore.

Stop if any identity, team boundary, resource mapping, provider target, or rollback step is ambiguous.

Secret and credential cutover

Rotate or introduce production credentials independently from graph promotion:

1. provision the new provider credential, Source secret, Destination secret, or project key in its owning system;
2. grant only the permissions required by the Trigger or Action;
3. update FastHook through the authenticated UI or API without exposing the value in a graph file;
4. validate the new credential with a safe request;
5. keep the previous credential valid only for a bounded overlap when the provider supports it; and
6. revoke the old credential after the canary and observation window pass.

If the provider cannot overlap credentials, schedule a short cutover window and define the exact pause, update, validation, and resume sequence. Follow Secrets and credential rotation for exposure response.

Activate a controlled canary

FastHook does not provide a generic percentage-based Workflow rollout control. Create a canary through the event source or graph design—for example a dedicated test Source, provider sandbox event, explicit allowlist Filter, or a separately controlled known-safe route.

1. record the Workflow version that will process the canary;
2. activate only the bounded canary path or Workflow;
3. send a uniquely identifiable event;
4. inspect the Trigger, Step order, mappings, provider response, and error route in Audit;
5. verify the resulting business record in the destination system;
6. confirm no unexpected duplicate or out-of-scope side effect occurred; and
7. retain the request ID, run ID, version evidence, and provider result.

Do not use an ordinary production event as the first unbounded test.

Observation gate

During the release window, compare current values with a recorded baseline:

• failed and pending Workflow runs;
• Step error codes and provider rate-limit responses;
• Trigger channel state, active alerts, fallback, and delivery mode;
• run volume, duplicate indicators, and processing latency;
• monitoring query completeness and result limits; and
• provider-side or ledger-side reconciliation.

Use the monitoring API example for technical signals and reconciliation reports for missing, duplicate, or unexpected business work. Extend the observation window when traffic is too low to exercise critical Paths.

Expand or stop

Expand only when the canary meets every recorded threshold and the monitor itself is healthy. Record the activation time and the new Workflow version because changing lifecycle status also creates a new version.

Pause expansion and begin containment when you see:

• an unexpected external side effect;
• a material increase in failed, pending, or duplicate work;
• a Trigger in error or unexplained fallback;
• incomplete monitoring windows;
• provider authorization or rate-limit failures; or
• a mismatch between FastHook success and the business system of record.

Follow the incident response runbook for severity, evidence, containment, and communication.

Roll back safely

FastHook retains immutable version evidence, but there is no restore-version endpoint. Rollback is a forward change:

1. contain new work by pausing the affected Workflow or upstream sender;
2. retrieve the current Workflow and record its version;
3. prepare the last-known-good graph as a new update, remapped to the current production resources;
4. send the current integer version as the concurrency guard;
5. keep the restored graph paused or in a controlled state while validating it;
6. run a synthetic canary and verify the provider-side result;
7. resume bounded traffic, observe, and reconcile; and
8. separately repair or replay missed work only after assessing idempotency and duplicate risk.

Do not assume that reverting the graph reverses Actions already completed in external systems. Compensation, cancellation, or data repair is provider-specific.

Close the release

• [ ] Final Workflow ID, version, status, and activation time are recorded.
• [ ] Canary request ID, run ID, Step evidence, and business outcome are attached.
• [ ] Monitoring remained complete through the observation window.
• [ ] Old credentials were revoked or their expiry is scheduled.
• [ ] Reconciliation found no unexplained missing, duplicate, failed, or unexpected work.
• [ ] Any paused sender, temporary Filter, test Source, or canary allowlist was removed or assigned an owner and expiry.
• [ ] Runbooks, environment inventory, and rollback payload match the released graph.

For repeatable releases, keep the non-secret promotion manifest, reviewed graph payload, release record, and verification evidence under the same release ID. Start with Environments and release management and Configuration promotion.