Workflow templates and duplication

FastHook recipes are reusable Workflow patterns, but the current dashboard does not expose a one-click template gallery, full-Workflow duplicate command, or import/export dialog. Build from a recipe, duplicate individual graph items in the builder, or create a new Workflow from an existing graph through the API.

Start from a recipe

Choose the pattern closest to the business outcome, then replace its example providers and fields:

• Google Sheets → Slack for polling or row events followed by a mapped message.
• GitHub → Linear for one app event creating a resource in another app.
• Stripe event routing for multiple named Paths and a fallback.
• Webhook → Google Sheets for generic ingress and structured row mapping.
• Transform before an API Action for payload normalization.
• Handle a failed Action for an explicit error route.
• Delayed follow-up for durable waiting.

A recipe describes a pattern, not a deployable object tied to your team. You still choose the Source, connected accounts, target resources, and mappings.

Duplicate a Step

Open the Step menu and select Duplicate. Paths splitter nodes are structural and cannot be duplicated as ordinary Steps.

The builder:

1. creates a new Step ID and a unique name such as Send message copy;
2. copies the Step configuration;
3. places the copy below the original;
4. connects the original success/default output to the copy with passthrough mapping; and
5. moves the original success/default downstream routes so they start after the copy.

This changes execution from Original → Next to Original → Copy → Next. It does not create a parallel branch. Review the duplicate’s connected account, target, mapped fields, and side effects before producing another event.

The original error route is not copied to the new Step. Add a separate error route when the duplicate also needs recovery behavior.

Duplicate a Path

Open a named Path menu and select Duplicate. A Paths Step supports at most 10 Paths.

The duplicate receives a new Path ID, copies the current condition groups, and is inserted after the original. It is not automatically connected to the original Path’s downstream Steps.

A fallback is unique. Duplicating the fallback creates a normal custom Path with empty conditions instead of a second fallback. Configure its conditions and connect its first Step before testing.

Copy a complete Workflow through the API

Whole-Workflow copy is currently an API procedure:

1. Retrieve the source Workflow with GET /v1/workflows/:id.
2. Create a new JSON body from name, description, source_id, steps, and edges.
3. Change the name and set status to draft.
4. Replace the Source or any team-scoped resource references that should differ.
5. Create the copy with POST /v1/workflows.

FASTHOOK_API_BASE="${FASTHOOK_API_BASE:-https://api.fasthook.io}"

curl --fail-with-body --silent --show-error \
  --header "Authorization: Bearer $FASTHOOK_API_KEY" \
  --header "x-team-id: $FASTHOOK_TEAM_ID" \
  "$FASTHOOK_API_BASE/v1/workflows/$SOURCE_WORKFLOW_ID"

curl --fail-with-body --silent --show-error \
  --request POST \
  --header "Authorization: Bearer $FASTHOOK_API_KEY" \
  --header "x-team-id: $FASTHOOK_TEAM_ID" \
  --header "content-type: application/json" \
  --data @workflow-copy.json \
  "$FASTHOOK_API_BASE/v1/workflows"

The create payload has this shape:

{
  "name": "Order alerts — staging copy",
  "description": "Copied for controlled validation",
  "source_id": "src_staging",
  "status": "draft",
  "steps": [],
  "edges": []
}

Replace the empty arrays with the retrieved graph after reviewing it. FastHook validates the copied graph, Source, and referenced resources and creates a separate Workflow at version 1. The name must be unique within the team.

Same-team and cross-team copies

A same-team copy can reuse compatible connected accounts and resources. It also inherits their operational dependency: revocation or permission changes can affect both Workflows.

Do not paste an unchanged graph into another team. Source IDs, provider accounts, reusable Destinations, filters, and transformations are team-scoped. Rebuild or remap those references in the destination team, reconnect accounts, and validate every Action with a controlled event.

Validate a copy

• Keep the new Workflow Draft or Paused until its Source and accounts are correct.
• Rename Steps so Audit distinguishes the copy from the original pattern.
• Open every Action and confirm provider, operation, auth mode, account, and target resource.
• Rebuild mappings from the new Trigger sample when the Source changed.
• Test every custom Path, the fallback, and each critical error route.
• Confirm Delay durations and retry-safe side effects.
• Activate only after the production-readiness checklist passes.

For immutable snapshots and safe changes, continue with Workflow versioning and migrations.