Phase 3: Test & Iterate

A workflow earns trust by running. This phase is the loop you'll live in: rehearse the draft, launch it for real, review what happened, fold fixes back into the graph, and publish when you're ready.

Simulate

Simulate rehearses the workflow step by step in a real browser, with you riding along. It exists to catch surprises before the first real launch, and a few minutes here usually does.

The rail lists every step of the workflow. As the simulation reaches each one, you have a small set of actions:

• Comment. Leave a note on the step ("the ETA is on the second tab, not the summary"). Notes become graph edits later, not just annotations.
• E-mail poll (OTP). Mark the step as one that needs a code or value from the team inbox at run time.
• HITL. Mark the step as one where a human should take over the browser.
• Lock. Mark a step as already correct so later feedback leaves it untouched.
• Next. Advance the rehearsal to the following step.

When you reach the end, click Apply Feedback. Everything you marked (comments, OTP flags, HITL flags) is folded into the draft graph in one pass, and you can review the changes on the canvas before publishing.

Launching a draft vs. a published workflow

While you're iterating, you can launch the draft from inside the workbench with the Launch workflow button; the run uses the draft graph exactly as it stands. Publishing is what makes the workflow real for everyone else:

• the Launch button appears on the Workflows page,
• email and schedule triggers go live,
• and the workflow is exposed as a REST endpoint.

The History tab

Every session this workflow has ever had, authoring sessions and launches alike, is listed in the workbench's History tab with a status badge (Completed, Cancelled, Failed), a timestamp, and a duration.

Open a session and you get two things side by side:

• The recording player in the center replays the browser exactly as the run saw it, so you can scrub to the moment something went sideways.
• The Session log on the right is a read-only transcript: the chat, each step with its status, and the final output. Read the log top to bottom and you can answer the two questions that matter after any run: what did it do, and what did it return. Step entries name the block that executed, so a failure points you straight at the block to inspect in the editor.

For the workspace-wide view across all workflows, with the same replay, head to the Sessions page.

Fix available

When a run fails, you don't start from a blank diagnosis. Back in the workbench, an amber Fix available chip appears above the editor composer, naming the failed step and a suggested repair. A worked example:

1. A nightly run of the Limit lookup workflow fails at the Sign in to Limit step: the portal shipped a redesign and the login form the agent expected isn't where it used to be.
2. The workbench shows Fix available with the failed step and the proposal: update the sign-in block's instructions to match the new login page layout it observed during the failed run.
3. Click Fix (or Fix all when several steps need repair). The editor applies the change to your draft and reports it as a normal patch summary.
4. Review the updated block, optionally simulate the sign-in step, and republish. The next scheduled run picks up the repaired version.

Generate an SOP

Once a version is stable, you can generate a visual SOP: a screenshot-grounded slideshow that documents exactly what that workflow version does, shareable with people who never open RamAIn. See Visual SOPs.

Publishing changes

Edits never go live by themselves. Everything you change in the Editor (chat edits, applied fixes, simulate feedback) accumulates in the draft. Publishing promotes the draft to the launchable version; runs already in flight finish on the version they started with. That means you can iterate freely on a workflow your team is actively using, and ship the improvements in one deliberate step.

A healthy iteration rhythm

Launch, check History, apply the fix, simulate the changed steps, publish. Most workflows converge in a couple of loops.