Runbooks

A Runbook is an ordered sequence of Tasks you can play with one click. Instead of kicking off five tasks by hand every Monday, you assemble them once into a runbook — then press Play and your agent works through them in order. It's the repeatable "recipe" version of your everyday process.

What Is a Runbook?

A runbook is a named list of tasks, in the order you want them run. When you play it, your agent picks up the first task, does the work, moves to the next, and so on — recording the result of every step along the way.

Two things make runbooks powerful:

• They're repeatable. Build the sequence once; run it as often as you like.
• They don't disturb your board. Playing a runbook runs the work but doesn't change each task's own status — a task sitting in "To-Do" stays in "To-Do." The runbook keeps its own separate history of what happened, so your kanban stays clean.

When to Use a Runbook

Use a single task when it's a one-off. Reach for a runbook when you have a process — a set of steps you repeat, ideally in a specific order. If you've ever written yourself a checklist like "every Monday: pull the numbers, draft the update, post it" — that's a runbook.

Creating a Runbook

Adding & Arranging Tasks

Inside a runbook, click Add task and search for any of your existing tasks to drop it in as a step. A task can be a step in more than one runbook, so reusable building blocks (like "Post the weekly update") can appear wherever they're useful.

Steps run top to bottom. Drag the handle on the left of any step to reorder them until the sequence matches your process. To take a task out of a runbook, click the × on its row (this only removes it from the runbook — the task itself is untouched).

Requiring a Step to Complete

Each step has a must complete toggle. It controls what happens to the rest of the runbook if that step doesn't succeed:

• On — if this step fails, the runbook stops here. The steps after it don't run. Use this for a step everything else depends on (e.g. "pull the data" before "write the report").
• Off (the default) — if this step fails, it's noted, but the runbook keeps going to the next step. Use this for a step that's nice-to-have but not a blocker.

A step "fails" when your agent hits an error it can't get past while doing the work (something went wrong, timed out, or was stopped) — as opposed to finishing the work and reporting back, which counts as success. Every step's result is recorded either way, so you can always see exactly what happened.

Setting a Success Condition

A runbook can have an optional success condition — a plain-English description of what a good run looks like (for example, "a draft post was created and a summary was produced"). When the steps finish, your agent checks the results against that condition and marks the whole run succeeded or failed accordingly. Leave it blank and a run simply succeeds when every step succeeds.

Playing a Runbook

Press Play and the runbook starts. A live progress panel shows each step as it goes — a spinner on the step that's currently running, a green check when it finishes, a red mark if it fails, and a dash for any step that was skipped. You can expand View output on any completed step to read exactly what your agent produced.

Need to bail out mid-run? Click Stop — the current step wraps up and the rest are skipped. Remember: none of this changes your tasks' own statuses; the runbook tracks everything separately.

Run History & Results

Every play is saved under Run history on the runbook, with its status and time. Expand any past run to see how each step turned out and to read its output again. The runbook header also shows a success rate across runs, so you can spot a step that's been flaky.

Scheduling & Automatic Triggers

Beyond pressing Play, a runbook can run itself — on a schedule, or whenever another system calls it. Open a runbook and click Triggers to set these up. (Available in the web app; desktop is on the way.)

Run on a schedule

In Triggers → Schedule, switch it on and choose how often — hourly, daily, or weekly — the time of day, and your timezone (weekly also lets you pick which days). Multify then plays the runbook automatically at those times, correctly handling daylight-saving changes. You'll see the next scheduled run right in the panel, and every scheduled run appears in Run history just like a manual one.

Trigger from another system (webhook)

A webhook lets another app kick off a run by calling a web address. In Triggers → Webhook, switch it on and copy the URL. Then choose how it's protected:

• Require a secret (recommended) — the caller must present the secret you're shown. You can regenerate it any time, which instantly invalidates the old one.
• No authentication — anyone with the URL can start a run. Only use this for low-risk runbooks.

To start a run, the other system sends a POST to the URL. When a secret is required, include it as an Authorization: Bearer <secret> header (an X-Runbook-Secret header or ?secret= query also work). You can include a JSON data object in the request body — Multify passes it straight through to the completion postback below, so you can tie a run back to whatever triggered it.

Get notified when a run finishes (postback)

Set a Completion postback URL and Multify will POST a summary there every time the runbook finishes — no matter how it was started. The summary includes the runbook name, the final status, the sequence of tasks that ran and how each turned out, the number of tasks, and start/finish timestamps. If the run was kicked off by a webhook that included a data object, that same data is echoed back so your system can match the result to the original request.

Example Runbooks