Workflow deprecation and retirement

Retirement stops an automation without losing the evidence needed to prove that producers, consumers, alerts, credentials, and recovery procedures were handled. Use paused for temporary operational containment and disabled for an inactive Workflow retained for management or compatibility.

FastHook does not currently provide a separate archived Workflow state. Do not use DELETE as an archive operation.

Choose the lifecycle action

| Action | Use it for | Reversible | Evidence impact | | --- | --- | --- | --- | | paused | Incident containment, maintenance, or short investigation | Yes | Workflow definition and current API-visible run history remain | | disabled | Deprecation or long-term inactive retention | Yes, through a new status update | Workflow remains available for inspection and reconfiguration | | DELETE /v1/workflows/:id | Final destructive removal after retention approval | No API restore | Database graph, version, run, and Step-run rows are cascade-deleted |

Only active Workflows are eligible to start new runs from Source events. Events received while a Workflow is paused or disabled are not documented as automatically backfilled when it becomes active again.

Deprecation record

Record:

• team ID, Workflow ID, name, current version, Source ID, and status;
• business and technical owner;
• reason, replacement Workflow or process, and migration deadline;
• producers, downstream consumers, connected accounts, reusable resources, and shared Source impact;
• last expected event time and required quiet period;
• alert, runbook, reconciliation, credential, and provider-subscription changes;
• evidence-retention requirement and deletion approver; and
• reactivation and rollback decision maker during the deprecation window.

Mark the Workflow visibly as deprecated in the external inventory. A name prefix can help operators, but it is not a substitute for the lifecycle record.

Before disabling

1. run dependency impact analysis;
2. identify every producer and business consumer, including systems outside FastHook;
3. confirm a replacement has processed representative events and reconciles successfully;
4. define how events arriving during the inactive period will be handled;
5. retrieve and retain the reviewed graph, current version, and non-secret dependency inventory;
6. choose a quiet period long enough to cover the slowest normal producer schedule; and
7. announce the cutoff, validation owner, and reactivation deadline.

Do not disable a shared Source just to retire one Workflow. A Source can start several active Workflows and may also participate in direct webhook Connections.

Disable and observe

Update the Workflow status to disabled using its current integer version. The status update creates a new Workflow version. Record the returned version and time.

During the quiet period:

• confirm no new runs start for the disabled Workflow;
• verify the replacement receives the expected events;
• reconcile expected business work with provider-side results;
• monitor shared Source and Instant Trigger health independently;
• investigate late producers, scheduled events, retries, and manual replays; and
• keep credentials and rollback available until the observation gate passes.

Existing queued or running work may require separate incident handling. Do not infer that a status change reverses an external Action already completed.

Retire dependencies in order

After the quiet period:

1. remove provider webhooks or polling configuration only when no other Trigger depends on them;
2. revoke provider credentials only after all Trigger and Action dependencies are clear;
3. disable or remove reusable Destinations, Filters, and Transformations only after checking Workflows and direct Connections;
4. update alerts, runbooks, dashboards, reconciliation jobs, and ownership records;
5. remove temporary migration routes and test allowlists; and
6. retain the final status, version, graph hash or payload, last run evidence, and approval according to policy.

Resource names are not a reliable dependency check. Match stable IDs and inspect embedded Action configuration.

Destructive deletion gate

Delete only when all of these are true:

• the Workflow remained disabled for the approved quiet and evidence-retention periods;
• inventory and dependency scans are complete;
• no producer, consumer, alert, runbook, or reconciliation job still expects it;
• required Audit and business evidence was exported to an approved non-secret record;
• credentials and shared resources have independent owners or are already retired;
• the replacement’s business outcomes reconcile; and
• an authorized owner accepted that the API provides no restore for the deleted Workflow.

Immediately before deletion, retrieve the Workflow again and compare its ID, status, and version with the approved retirement record. Abort if it is active, changed, or no longer matches the reviewed graph.

Close or reactivate

If retirement succeeds, record the deletion response, time, operator, and evidence location. If validation fails, keep the Workflow definition, assess events missed during inactivity, reactivate only with the latest version, run a canary, and reconcile before resuming normal traffic.

Continue with Data handling and retention, Workflow versioning, and Incident response.