Running, Sandbox & Fixes

Once the graph looks right, you run it. This page covers the two run modes, where runs live, human approvals, and the part people like most: what happens when a run fails.

The run dialog

Click Run in the builder header to launch:

• Inputs (JSON): the values the automation's Input block asks for.
• Input files: attach spreadsheets, PDFs, or anything else the run should work on; they're available to every step as inputs.files.

Then pick the mode: Sandbox run or Run live.

Sandbox vs. live

Tab: Sandbox run

A sandbox run executes the current draft, no publish required, with side effects switched off:

• No real emails are sent.
• No real browser sessions launch; browser steps return realistic placeholder results shaped like their real outputs.
• Write-style HTTP is simulated; read-style requests can stay live, so the run still works with real data where it's safe to.
• Approval pauses auto-pass, so the run flows end to end.

This is the way to test while you iterate: change the graph in chat, hit Sandbox run, watch it flow, repeat. Nothing outside RamAIn is touched.

Tab: Run live

A live run does everything for real: real browser sessions, real HTTP writes, real emails, real approval pauses. Live runs require the automation to be Published, and they execute the published version, so you always control exactly when changes take effect.

What that means in practice

Take the Zoho pipeline from the overview page and run it in the sandbox. Here is what each step actually does:

So a sandbox run proves the shape of the whole pipeline (the fetch works, the loop fans out, the CSV builds, the delivery is wired) without creating ten orders in Zoho or emailing anyone a test file.

Code runs for real in both modes

Code steps always execute in an isolated sandbox, in sandbox runs and live runs. That isolation is about safety, not simulation: your Python or TypeScript genuinely runs and produces real results either way.

Following runs

Toggle Runs in the builder header for this automation's history: every run with its status (queued, running, waiting approval, completed, failed), a Sandbox or Live tag, duration, and result.

Open any run for the step-by-step trail: what each block received, produced, and how long it took. Parallel loop iterations appear as separate live rows, so you can watch each item move.

For the workspace-wide picture, Sessions has an Agents tab listing runs across all your automations in one place.

A few things you can do from a run:

• Approve and resume / Reject: when a run is waiting approval at a Wait block, review its output so far and decide. Approving resumes exactly where it paused; rejecting ends it.
• Stop: cancel a running automation; in-flight steps are aborted cleanly.

When a run fails: self-healing and fixes

Deterministic steps (code, transforms, API calls) occasionally hit reality: an API adds a field, a date arrives in a new format, a response shape shifts. On RamAIn, that doesn't have to mean a dead run.

Step 1

The run self-heals in flight. When a deterministic step errors, an agent inspects the failure and repairs the step on the spot. The run continues with a corrected output and completes instead of failing.

Step 2

The repair is recorded as a proposed fix. A sparkle badge with a count appears in the builder header: "Runs failed at these steps and self-healed. Review the permanent fixes."

Step 3

You review it. The Available fixes panel shows each step that failed, what went wrong, the original error, and the suggested permanent fix, with Apply fix and Dismiss.

Step 4

Applying hands it to the builder. The builder chat patches the draft with the fix; you review the change like any other edit and publish when ready.

A worked example

Back to the Zoho pipeline. During a few runs, one loop item errored: the browser workflow returned an error object instead of an order, and the Build CSV Python step, which assumed every loop result contains order_number, crashed with a KeyError on that row. The run self-healed (an agent repaired the step in flight, and the CSV still went out), and the sparkle badge appeared in the header. Clicking it opens the panel:

The card tells the whole story in one place:

• Which step: Build CSV, with how many runs it recovered and when it was last seen.
• What happened: the CSV step assumed every loop result contains order_number, but runs where the browser workflow failed return an error object instead.
• The original error, expandable: KeyError: 'order_number' at row 7 of the loop results.
• The recommended fix: guard the row mapping so a missing field becomes an empty value instead of a crash, and add a separate errors column so failed lookups are visible in the CSV rather than silently absorbed.

From here you choose:

• Apply fix hands the proposal to the builder chat. The builder patches the draft, narrates the change with the usual per-node "changes made" summary, and the canvas updates. Nothing goes live until you publish, so you review the repair like any other edit.
• Dismiss removes the proposal without touching the graph, for the cases where the failure was a one-off you don't want to design around.

The result: every failure becomes a proposed improvement that you approve. The run that hit the problem still finished, and once you apply the fix, the next runs don't hit it at all.

Starting runs automatically

Beyond the Run button, published automations start from:

• API: POST from your own systems; see the API reference.
• Schedule: a recurring interval.
• Email: a matching message to your team inbox, with its body and attachments passed in as inputs.

All of these are configured on the Triggers page under the Agents tab. Email and schedule triggers fire once the automation is published.

Building Blocks

Every block type on the canvas, and when to reach for each.

Triggers

Manual, API, schedule, and email starts, for workflows and agents alike.