The workflow¶

A workflow is one repeatable business process (customer onboarding, expense approval, a manufacturing checklist) captured so it can run again and again, the same way each time.

You don't write it alone. You describe the process, and Malleable models it with you: the way you'd sketch a flowchart on a whiteboard with a coworker, asking questions and redrawing as you go. The result is a diagram on a canvas: stages left to right, the tools each step uses, and where the process waits on someone.

That diagram isn't a picture of the software. Once you publish it, it is the software: every run executes the workflow you drew. The rest of this page is what a workflow is made of.

Stages & components¶

A workflow is organized into stages, the phases of your process, in the order they happen. Each stage holds components: the concrete building blocks that do the work. The component reference lists every type; this section explains how they fit together.

Here's a small example, a daily customer-meeting digest (this is the same live diagram you work with in the product):

The cards are stages; the chips inside each are its components; the arrows show the order they run in.

When several components work toward the same thing, they can be grouped into a named skill — "Manager Notification", say — with a line describing how it usually runs, like "runs once, then waits for a reply". A stage with a dozen components becomes three or four named groups you can read at a glance.

The agent sees those groups too, and it takes them as intent rather than instruction. It still decides what to do and when, so a skill described as a daily check won't stop it acting sooner when something needs attention.

Stages¶

A stage groups related work and carries guidance: plain-English instructions for how the work in that stage should go. Guidance is where your business rules live: "chase a missing receipt before approving", "use the rejection email if the request was denied". A stage that waits on somebody is a hand-off.

Traditional workflow tools make you spell out every condition, branch, and loop. Malleable doesn't, because Malleable also carries out every run. It reads your guidance and applies judgment the way a capable coworker would, so plain instructions are enough.

Stages connect to their successors explicitly. A stage with no successor ends the workflow; one successor always advances to the next stage. When a stage has several successors (a fork, like the approve vs. reject split in the diagram above), each branch carries a plain-English condition for when it's taken, like "the manager approved" or "no reply within 48 hours". Malleable picks one path during the run from those conditions and the data collected so far. Branches can re-converge later, and hovering a stage on the canvas shows the conditions on its neighboring stages.

For work that should run in parallel or in isolation, say one ticket per attendee, workflows use sub-workflows instead of forks.

How Malleable uses components during a run¶

Some parts of a workflow are settled when you build it, and some are decided fresh on each run. A component like "send the approval email" does the same thing every time: it sends that email to whoever the run says it goes to. What varies (the name, the amount, the recipient) fills in as the run gathers it.

During a run, Malleable handles the judgment that can't be settled in advance: which branch to take, what to write in a free-form message, when to ask a clarifying question. When two situations genuinely need different content, like an approval notice versus a rejection notice, those are two separate components, and Malleable picks the right one during the run.

How a workflow starts¶

Every run begins at a starting point. A workflow can start from:

• A form. Someone opens the workflow's link and fills it in. See Form entry point.
• A schedule, such as every weekday at 9am in your timezone. See Schedule.
• An email sent to an address Malleable gives the workflow. See Incoming email.
• A Slack or Microsoft Teams message that mentions Malleable Bot in a channel you choose, or a direct message to it. You can describe in plain words which messages should count. See Slack trigger and Microsoft Teams trigger.
• Another app that sends a request to a web address Malleable gives the workflow. See Incoming webhook. AI apps can also start runs through MCP.

To add one, ask Malleable, for example: "Let vendors start this by emailing their invoices."

More than one starting point¶

One workflow can have several starting points, and each one can start at a different stage. Say employees submit expenses through a form, while vendors email their invoices. The form can start at "Check the expense" and the email at "Read the invoice". Both paths can then lead to the same approval stage.

On the canvas, each starting point is its own card, next to the stage it starts.

When there's more than one way to start, the Run menu lets you pick which one to use.

Hand-offs¶

Most stages do their work and move on. A hand-off is a stage that waits for a person instead: an approval, a review, a form somebody fills in.

During a hand-off, Malleable reaches out on the channel that person already uses — email, Slack, Teams — and pauses there. If they need to fill something in, the message carries an authenticated link to the form, so they do not need an account. Simple forms can be answered without leaving Slack or Teams. If you've named a channel for the stage (below), the form is simply there for them to answer — though it's usually still worth notifying explicitly.

The stage won't complete on its own until someone responds — unless you give it a deadline (below).

Who gets reached doesn't have to be fixed when you build the workflow. The same stage can notify a different person on each run, from an address or handle the run collected earlier.

A hand-off can also carry a deadline: if no one responds within the delay, the wait is satisfied on its own so the run can move on to the next stage instead of waiting indefinitely. It can send a reminder before that point too, if you asked for one when the hand-off was set up.

Who sees a run¶

People see a run through a channel: a named view, read either on a web link or in a Slack or Microsoft Teams conversation. You name each one — "the Requester", "the Manager" — and say which stages it reads, and how much of each: its messages, how the answer was worked out, the form it puts in front of someone, or the record of what each component did. One channel can follow a run across several stages.

Channels are optional. Without any, everyone who can open a run sees all of it. Once a workflow has one, each stage is seen only by the channels you show it to.

Sub-workflows¶

A sub-workflow is a workflow run as a step of another one. It's how you break a large process into pieces, each with its own stages and hand-offs, and how you run work in parallel.

The most common shape is fan-out: run the same sub-workflow once per item, like one review per approver or one audit per project. Each runs independently, so different people can work their part at the same time.

A later stage can wait for the results before it begins ("summarize once all four reviewers have responded"). See When a stage starts. Since people don't always respond, a sub-workflow can carry a time limit: when it's reached, the run continues with whatever came in.

The Sub-workflow component covers the configuration in detail.

When a stage starts¶

Most stages start as soon as the stage before them finishes. Some should wait until something is true. To set this up, ask Malleable. For example: "Don't place the order until at least 3 managers have approved." A stage can also wait for a sub-workflow to send back its results. To see what a stage is waiting for, click it on the canvas and look under Starts after.

Under Starts after, each condition is marked Required or Optional. The stage can start without an optional one.

Think about what should happen if a condition is never met. If only 2 managers approve, should the requester hear back? Tell Malleable, and it adds that path.

Data flow¶

As a run progresses, it gathers facts: who submitted the request, what amount, which decision was made. Malleable calls this collected data, and it's declared explicitly: each workflow defines what it collects, where each value comes from, and which components consume it. Each value can also carry its own description — what it means and what format it should take, checked when the value is stored — written once on the value rather than repeated in stage instructions. Explicit wiring is what lets the workflow be validated before it runs, instead of failing mid-run on missing data.

A stage can't complete until its required data has actually been gathered, so a run can't quietly skip a step that some later part of the process depends on.

Sensitive values can be marked secret: agents never see them, they're injected straight into the action that needs them.