CFFBRWCFFBRWDocumentation
⚠Auto-generated documentation — This content was generated with AI assistance and is currently under review. Information may be incomplete or inaccurate. When in doubt, contact our support team.

Runs & Execution

Every time you run a workflow, CFFBRW creates an isolated execution instance with its own Durable Object on Cloudflare's edge. This page explains what happens during a run and how to work with run results.

Starting a Run

You can start a run in several ways:

  • Dashboard — Click Run on any workflow
  • API — POST /v1/workflows/:id/run with optional variables
  • Webhook trigger — POST /v1/trigger/:workflowId (requires published workflow)
  • Cron schedule — Automatic on the configured schedule
  • MCP — Via the BYOA MCP run_workflow tool

Real-Time Streaming

Runs stream step-by-step progress to your browser via WebSocket. You'll see:

  • Steps light up as they start executing (shimmer animation)
  • Outputs appear as each step completes
  • The DAG updates node colors in real-time
  • Total execution time is tracked per step

Three-Tier Execution

CFFBRW uses a three-tier execution model to maximize reliability:

Tier 1: Deterministic

Steps run exactly as compiled. No AI involved at runtime. This covers all 12 step types: http_request, transform, code, conditional, loop, wait, mcp_call, connector, human_approval, ai_call, sub_workflow, and browser_action.

95% of steps succeed here.

Tier 2: AI Recovery

When a step fails, CFFBRW's AI diagnoses the error and attempts to fix it inline:

  • Retry with different parameters — modifies safe fields like URL params, connector body params, or timeout
  • Retry with alternate tool — tries a different MCP tool if available
  • Fixed output — AI provides the expected result directly
  • Code fix — AI writes a JavaScript snippet to transform or repair the result
  • Retry with hint — if a human is involved (approval gate), they can provide guidance and the AI re-attempts with that context
  • Escalate to human — if 2 recovery attempts fail, pauses for human input

For connector and HTTP steps, the recovery AI sees the full catalog of available actions, the resolved request body, and workflow input, so it can make informed fixes.

Recovery happens automatically. You'll see a blue "Adapted" badge on recovered steps. Successful recoveries are logged and fed back into future compilations to prevent the same failures.

4% of steps are AI-recovered.

Tier 3: Plan Evolution

Recovery wins and compile errors accumulate over time. When you click Improve Plan, this history is injected into the recompilation prompt, producing a smarter plan that avoids past failures.

This is not automatic — it's triggered when you provide feedback or click Improve Plan.

Run Statuses

StatusMeaning
runningSteps are currently executing
completedAll steps finished successfully
failedOne or more steps failed after recovery attempts
pending_approvalWaiting for human approval on a gate step
pausedManually paused or waiting for external input

Viewing Run Results

Step Detail Drawer

Click any step node in the DAG to open the detail drawer showing:

  • Step type and configuration
  • Input references — which previous steps provided data
  • Output — the full result (JSON, text, or error)
  • Execution time
  • Recovery history — if Tier 2 recovery was triggered, what was tried and what worked

Terminal Nodes

The workflow's final output is collected from terminal nodes — steps with no dependents. If there's a single terminal node, its output is the run result. If there are multiple, outputs are collected into a { step_N: output } map.

Pruned Steps

For conditional workflows, steps in branches that weren't taken appear at 50% opacity with a scissor badge. These were compiled but skipped at runtime.

Rerunning

After a run completes (or fails), you can:

  • Rerun the entire workflow — starts a fresh execution with the same plan
  • Rerun from a specific step — re-executes from a failed step onward, keeping earlier results

This is useful for debugging: fix a step's upstream dependency and rerun from the point of failure.

Run History

Each workflow maintains a full run history. Go to your workflow → Runs tab to see:

  • All past runs with status, duration, and timestamp
  • Click any run to view its DAG and step outputs
  • Each run preserves the exact plan version it used — even if you've since recompiled

Approval Gates

Workflows can include human_approval steps that pause execution:

  • Human approval (purple) — Waits up to 24 hours for a user to approve or reject
  • Recovery approval (blue) — Waits 5 minutes during Tier 2 recovery

When a run hits an approval gate:

  1. The run status changes to pending_approval
  2. An entry appears in your Approvals inbox (sidebar)
  3. You (or any workspace member) can click Approve or Reject
  4. The workflow resumes or terminates based on your decision

See the Approvals page for more details.