Building Workflows

A workflow is a process: something comes in, steps run, something goes out. That's also the easiest way to describe one to Forge — as a sentence with arrows in it.

Describe the process

You:   Build a workflow: an order comes in via HTTP, check that the
       item is in stock, save the order to the database, and respond
       with 200 and the order id.

Forge reads your database schema to find the right tables, plans the steps, and builds the draft: an HTTP entry point, a stock check, a database write, and the response. You'll see the progress panel tick through the steps and a Changes made summary with a link to the finished workflow — open it to see the graph on the canvas.

Forge starts with the happy path — the case where everything works. That's deliberate: a running skeleton first, edge cases second.

Add the branches

You:   If the item is out of stock, respond with 410 instead.

Forge adds the branch and its condition, and updates the responses. Conditions, loops, error handling — all of it can be requested the same way: describe the business rule, not the node mechanics.

You:   And wrap the database write in error handling — if it fails,
       respond with 500 and log the error.

Forge runs it before you do

After building, Forge verifies its work by running the draft with test data:

Forge: I ran the workflow with a test order:
       — item in stock  → 200, order saved, id returned ✓
       — item missing   → 410 ✓
       One issue: the stock check compared against the "reserved"
       field instead of "available". I fixed it and re-ran — both
       cases pass now.

Test runs happen in design-time and show the result of every step, so when something fails you see which node failed and with what data — and so does Forge, which is how it fixes its own mistakes.

Debugging existing workflows

Forge is just as useful on flows it didn't build:

You:   The order workflow failed a few times this morning. Why?
Forge: I checked the recent execution logs. Three runs failed at the
       "Save order" step: the "customer_email" field was empty and
       the table requires it. The requests came from the mobile app.
       Want me to make the field optional, or add a validation branch
       that responds 400 when the email is missing?

It reads the execution logs step by step, finds the failing node, and proposes fixes — which then go through the usual approvals.

Organizing workflows

Housekeeping requests work too: "move the order workflows into an 'Orders' folder", "rename this workflow to Order Intake". Deleting a workflow is a high-risk change — expect a red approval card.

Next steps