> ## Documentation Index
> Fetch the complete documentation index at: https://docs.get-hive.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Workflows that read your tools
> The useful business automations start by reading real data, route with judgement, and rehearse before they send. A practical guide to designing them.
22 September 2026 · The Hive team
Classic automation tools are built around events: when X happens, do Y. That works for plumbing — copy a new row here, post a message there. It struggles with the work people actually want off their plate, which rarely starts with a clean event and almost always needs judgement in the middle.
"Every morning, find the invoices that are overdue and chase them" is not an event. It is a read, a decision per invoice, and a carefully worded message. This post is about designing workflows for that kind of work: ones that **read** your tools, **route** with judgement, and **rehearse** before they touch anything real.
## Start with a read, not an event
The most useful workflows begin by gathering context. In Hive's [workflow builder](/workflows/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.
Reading first has a practical benefit: the workflow works on the state of your business *now*, not on whatever the last webhook happened to carry. It also means the workflow can be run on demand when someone asks "can you just check?".
## 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.
A good habit: keep the AI condition's choices few and mutually exclusive, and keep **Force AI to select a path** on only when every item really does belong to one of them. Otherwise leave an **else** path for anything the model is unsure about, and send that path to a person. See [Triggers and steps](/workflows/workflow-steps).
## 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?
You can run the whole flow, run from a particular step onwards, or run a single step, and feed it sample form input or replay recent real submissions. See [Test and deploy](/workflows/test-and-deploy).
## 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](/workflows/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](/workflows/workflow-assistant) drafts the graph as a proposed change you can apply or reject. Or start from one of the built-in [templates](/workflows/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
1. Does the workflow start by reading the current state, rather than trusting an old event?
2. Is every mechanical decision a rule, and every fuzzy decision an AI condition with an escape path?
3. Does every loop have a maximum you would be comfortable hitting?
4. Have you test-run it with realistic input and read every shadowed action?
5. Does each step's error setting match how much the rest of the run depends on it?
6. Would you be comfortable explaining the deploy description to a colleague in a month?
Workflows designed this way do real work — and stay understandable to the people responsible for them.
Your first workflow, step by step.
Every trigger and step, with its settings and limits.