22 September 2026 · The Hive team
Start with a read, not an event
The most useful workflows begin by gathering context. In Hive’s workflow builder, a workflow has exactly one trigger — Manual, In-app form, Public form or Schedule — and the first step is usually an agent that reads a connected tool:- a daily schedule that asks an agent to find overdue invoices in Xero;
- an hourly schedule that reads new Zendesk tickets;
- a form a colleague fills in when a signed engagement letter arrives.
Put judgement where the judgement is
Between reading and acting there is usually a decision. Is this ticket urgent? Is this email unusual? Does this client need a different tone? Rules handle some of that; many real decisions are fuzzy. Hive’s Condition step has two modes, and choosing between them is one of the most important design decisions in a workflow:- Rule mode compares a value — equals, contains, greater than, exists. Use it whenever the decision is genuinely mechanical: an amount over a limit, a field that is empty.
- AI mode gives a model a set of named conditions (“urgent”, “billing question”, “anything else”) and asks it to choose a path, recording why it chose. Use it when a person would have to read the content to decide.
Loop deliberately
Most operational work is “for each”: for each overdue invoice, for each ticket, for each renewal. A Loop step takes a list from an earlier step and runs its body once per item, with an explicit maximum number of iterations (up to 500). Setting that maximum is not bureaucracy — it is how you guarantee a workflow cannot send 5,000 emails because an upstream read returned more than you expected. Hive refuses to deploy a workflow whose worst case could exceed its per-run step budget, and tells you why. Where the items are independent, Parallel execution runs up to five at once. Where you need several perspectives on the same input — research the client, then separately review the risks — a Parallel agents step runs two to five agents side by side and hands you each answer plus a combined digest.Rehearse before you send
The single most valuable feature in any automation tool is a rehearsal that is faithful but harmless. In Hive, a test run executes your current draft for real — the models run, the reads happen, the loop iterates — but every action is shadowed: marked “Not sent: this was a test run”, with the payload it would have sent shown under Would have sent, and never sent. Duration waits are skipped so you are not kept waiting. That lets you answer the questions that matter before anything goes out:- Did the read find the right records, and only those?
- Did the AI condition route each item the way a person would?
- Is the drafted email one you would be happy to send?
Deploy with a version and a description
When a workflow is right, deploy it. Each deploy creates a numbered release — patch, minor or major — with a required description of what changed. Past versions stay listed and can be re-activated, and pausing a workflow stops new runs without cancelling ones in flight. It is a small discipline that pays off the first time someone asks “what changed on Tuesday?”.Actions still go through the gate
A deployed workflow does not get a pass on safety. In production, every action step goes through the same approval and policy gate as anything else in Hive. Depending on your policy, it runs, it waits for approval, or it is only simulated — and actions that write to a connected tool on your behalf are routed to a person to approve. Each step also has its own error setting — retry, stop, or continue with an empty output — so one flaky call does not have to sink the whole run. See Runs and errors.Let the assistant draft, and you decide
You do not have to build from a blank canvas. Describe the job in the + Describe tab — “every hour, read new Zendesk tickets, tag each with its urgency, and alert the support team to anything urgent” — and the workflow assistant drafts the graph as a proposed change you can apply or reject. Or start from one of the built-in templates, such as Fee Reminder, Ticket Triage or New Client Onboarding. Either way, the draft is where the work starts, not where it ends: read it, test it, and deploy it when the rehearsal looks right.A design checklist
- Does the workflow start by reading the current state, rather than trusting an old event?
- Is every mechanical decision a rule, and every fuzzy decision an AI condition with an escape path?
- Does every loop have a maximum you would be comfortable hitting?
- Have you test-run it with realistic input and read every shadowed action?
- Does each step’s error setting match how much the rest of the run depends on it?
- Would you be comfortable explaining the deploy description to a colleague in a month?
Build a workflow
Your first workflow, step by step.
Triggers and steps
Every trigger and step, with its settings and limits.