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/runwith optional variables - Webhook trigger —
POST /v1/trigger/:workflowId(requires published workflow) - Cron schedule — Automatic on the configured schedule
- MCP — Via the BYOA MCP
run_workflowtool
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
| Status | Meaning |
|---|---|
running | Steps are currently executing |
completed | All steps finished successfully |
failed | One or more steps failed after recovery attempts |
pending_approval | Waiting for human approval on a gate step |
paused | Manually 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:
- The run status changes to
pending_approval - An entry appears in your Approvals inbox (sidebar)
- You (or any workspace member) can click Approve or Reject
- The workflow resumes or terminates based on your decision
See the Approvals page for more details.