Visual Workflows That Run on Their Own
Most office automation is simple decisions repeated many times — "if a meeting is on the calendar tomorrow, prep notes from last week's transcript; if an invoice arrives, file it under the right vendor." Writing those rules in code is a developer's job. FactoryOS gives you a visual builder that lets you draw the same rules as a flowchart, and a runtime that takes the finished flowchart and runs it on its own.
Two surfaces sit at the heart of that. Workflow is the editor where you build the flowchart. Manifold is the runtime where it goes to actually live and execute. The loop is straightforward — build it, check it, send it to the Manifold, watch it run.
Building Without Writing Code
The Workflow editor is a canvas with a side palette of building blocks. The blocks come in three families. Triggers sit at the top and decide when the workflow starts. Processing blocks make up the middle — checks, branches, transformations, math, string handling, calls to the AI, anything that shapes data on the way through. Actions sit at the bottom and cause changes outside the workflow — sending messages, writing files, updating databases, the world-changing events that end the flow.
You drag a block onto the canvas, click it to fill in what it does, and draw lines from one block to the next to connect them. Each block has labeled inputs and outputs, so a line you draw between two blocks is meaningful — it tells the system which piece of data flows where. If you try to connect something that doesn't fit, the line won't take, which helps prevent wiring things wrong from the start.
The canonical shape of a workflow is one or more triggers, some processing, one or more actions — something happens, the system reacts, something gets done in response.
Saved Versus Running
A workflow lives in one of two states. Draft means it sits in the editor — you can change it freely, but nothing happens automatically. Ported and running means a copy is live in the Manifold, watching for its trigger to fire.
The top bar of the editor shows which state you're in. Switching between them is the whole point of the next two sections.
From Draft to Live
When the workflow looks right, the Validate button checks it. Validation walks the whole canvas and flags anything that won't work: a block missing required information, a line connecting two pieces that don't fit, a branch with no continuation. The success state is a single line — "Validation passed, no issues, ready to port" — and an unblocked Port to Manifold button next to it.
Press Port to Manifold and the workflow leaves the draft world and arrives in the live runtime. The editor button switches to Pull from Manifold, signaling that the draft is now a published copy. To change the workflow again, you either pull it back or detach it from the runtime first.
Triggers Decide When It Runs
A live workflow doesn't run continuously; it waits for a trigger. You pick one or more triggers when you build the flow, and it sits at the top of the canvas as the first block — the rest of the workflow runs every time the trigger fires.
The trigger options cover most of the events a workflow would want to react to:
- Schedule. Fires on a cron or interval — every weekday at 8am, every hour, every fifteen minutes. - Manual. A button on the workflow's row in the live dashboard that fires it on click. - Email Received. Fires when a new email is picked up by the inbox, with optional filters on sender, recipient, or subject. - Webhook. A web address that fires the workflow when another system calls it. - File Watch. Fires when a file in a watched folder is created, changed, or removed. - DB Row Event. Fires when a row is inserted, updated, or deleted in a configured table.
Beyond those, more specialized triggers fire when another workflow completes, when a human approves a request waiting in the queue, when an internal event is broadcast, or when a remote AI agent calls a skill this workflow exposes. The list is open-ended — each trigger is itself a building block, so the available types grow as FactoryOS does.
Processing Shapes the Data
Processing blocks fill the middle of every workflow — the steps that take what the trigger handed in, work on it, and pass results down to the actions. They cover the kinds of operations any process needs: checking a value, branching on a comparison, transforming text, doing math, parsing or stringifying JSON, filtering a list, holding a constant.
The most distinctive processing block is the one that calls the AI. Inside any workflow you can drop a step that hands a piece of work to the FactoryOS brain — "summarize this email," "extract the action items from this transcript," "draft a reply in this tone" — and pass the result to the next step.
That's the difference between a basic automation tool and FactoryOS's. The AI is a step you can use anywhere in the flow, not a separate product you have to wire up. The retrieval and reasoning that the personal assistant uses for chat are the same capabilities a workflow gets to call.
Actions Make Things Happen
Actions are the third family of blocks — the ones that reach out into the world and cause a change. Where triggers wake the workflow up and processing shapes data inside it, actions write something somewhere real: sending an email, posting to a webhook, writing a row to a database, dropping a file to disk, sending a chat message, generating speech, kicking off another workflow.
Most workflows end with an action. The pattern is straightforward — trigger → processing → action, do something when something happens. A new invoice email arrives (trigger), the workflow extracts the vendor and amount (processing), a row gets added to the bookkeeping database (action). A schedule fires at 7am (trigger), the morning briefing gets composed (processing), the briefing gets sent to the user's email (action).
A workflow can have multiple actions, and they can fan out — one event triggering a chain of changes. Actions can also be conditional, with a branch in the middle picking which action runs based on what the processing found.
Watching a Workflow Work
The Manifold page is the live dashboard for everything that's running. It lists every active workflow, shows how many are live, paused, and how many blocks and lines are deployed across them all, and reports the runtime's overall status. A workflow in flight shows what it's doing right now — "awaiting tick" between trigger fires, or actively processing during one.
Each workflow also keeps its own run log. Every time the trigger fires, the log records what came in, what each step did, and what came out — including the actual messages the workflow exchanged with the AI. So you can trace what happened on any past run instead of guessing.
Detach a Workflow Anytime
A published workflow isn't permanent. Open it in the editor and either Pull from Manifold to bring the draft back and stop the live copy, or Detach to stop the live copy and leave it removed from the runtime. Both are clean toggles — the workflow stops between runs, never mid-step, and the next time the trigger would have fired, nothing happens.
That keeps the whole loop low-stakes. Build, port, watch, pull, fix, port again. The runtime runs whatever version you give it, and you decide when to swap that version out.