Workflows

Define the report's audience and fixed sections first. Then identify each section's source, owner, refresh time, and verification method before automating collection or formatting.

Run one week manually with a small sample to expose missing data and unclear decisions. Add failure routing for late inputs, avoid duplicate output on retries, and require review of numbers and claims before distribution. The workflow should automate predictable assembly while keeping judgment visible.

Which section needs the most manual correction each week?

Split a workflow when its branches have different owners, outputs, review standards, or failure handling. A long canvas is not by itself the reason; the real question is whether each part has a separate promise.

Define the handoff between the two flows, including data format, authorization, and what happens if the second flow fails. Test both independently and together. If the split adds more coordination than it removes, keep one flow with a clear branch.

Which result has a separate owner?

Lead with the result, its purpose, and the decision you need from the recipient. Include a short note on inputs, what was checked, known limits, and where to find the approved output.

Avoid sending the entire workflow canvas unless someone needs to debug it. Explain skipped items or uncertain data in plain language, and remove private information the recipient is not authorized to see. Give a clear review deadline and contact for questions.

What decision should your teammate make?

Classify each checklist item as required input, repeatable action, human decision, or final output. Automate only steps with a stable rule; keep judgment points visible to the reviewer.

Define what happens when an input is missing and what a retry does to partial results. Test one ordinary path and one failure path with safe sample data. A workflow is ready when someone else can run it without filling gaps from memory.

Which checklist item still needs a person to decide?

Give reviewers a predictable output shape: task name, source or input summary, proposed result, exceptions, and the exact decision requested. Show before-and-after values when a transformation could change meaning.

Highlight skipped records and uncertain cases rather than hiding them in logs. Keep private data restricted to authorized reviewers. Test the format with one normal and one unusual sample; a reviewer should not have to reverse-engineer the workflow to understand the result.

What would cause a reviewer to reject this output?

Add a checkpoint after parsing, before irreversible actions, and before sharing the final output. Each checkpoint should have a concrete pass condition, a failed-state destination, and an owner.

Do not ask a human to recheck every trivial step; focus on data loss, privacy, money, and externally visible mistakes. Test one forced failure to confirm the workflow stops or routes it correctly, then verify retries do not duplicate work.

Which step is hardest to undo?

Use names that describe what a person provides: “Source CSV,” “Target time zone,” or “Report deadline.” Add units and accepted formats where confusion is likely.

Avoid names based on internal transformations, such as “Step 3 payload,” unless the operator genuinely works with that concept. Show a safe example and mark required fields. Test the form with someone unfamiliar with the workflow; their first question reveals a weak label.

Which input name gets interpreted two ways?

Automation pays off when a task repeats, its inputs and expected outputs are clear, and errors can be detected. Start by writing down the manual steps and timing one run. Then estimate how often the task occurs and how much effort it takes to build and maintain the workflow.

Keep a person in the loop for decisions that require judgment, involve sensitive data, or have costly irreversible effects. For a candidate workflow, define what happens with missing input, duplicate requests, failed steps, and retries before scaling it up.

Try a small, reversible example in Workflows. The goal is not to automate everything; it is to remove dependable repetition while retaining clear responsibility for the result.

Write a short runbook beside the workflow: what problem it solves, which inputs it accepts, where outputs go, and which steps can change external data. Include one safe sample input with its expected output.

Then record how to detect failure, whether a retry can create duplicates, who owns any secrets or external connections, and how to stop or undo a bad run. Note the last time you tested it. Screenshots of a node graph alone rarely explain why a branch exists or what assumptions it makes.

A useful check: could someone who did not build it run a test copy a month from now and tell whether the result is correct?

Use a small set of safe inputs whose correct outputs you already know. Test a normal item, an empty or malformed item, and a case that should fail. Compare each result against your expectation rather than accepting a green status indicator.

Next, deliberately interrupt a step and retry. Check whether the workflow duplicates messages, charges, or records, and whether the failure is visible to the operator. Only then try a realistic batch with limited scope and a way to undo mistakes.

For a workflow handling private or high-value data, use synthetic examples until permissions, secret handling, and failure paths have been reviewed.

A workflow is getting too complex when one small change affects unrelated branches, failures are hard to locate, or every run needs manual repair. Count not just nodes but responsibilities: can you state the input, output, and failure behavior of each section?

Extract a repeated transformation into a reusable step or split independent jobs into separate workflows. Define the data passed between them, then test normal, empty, malformed, and repeated input. Be careful with retries: splitting a workflow should not cause duplicate emails or records.

Keep one observable promise per workflow, with logs or status that reveal where it failed.

A reusable template needs more than a working graph. State what it does, which inputs a person must replace, what output to expect, and what external systems it touches. Use synthetic sample data and clearly mark placeholders for credentials, URLs, and IDs.

Provide one normal run and one failure example. Explain whether rerunning can duplicate or overwrite data, where errors appear, and which permissions are required. Remove your own secrets and private data before sharing in Workflows or a gallery.

Ask someone unfamiliar with the template to run a test copy. Their first question usually reveals the missing instruction.

Start by identifying what must be true before the workflow can proceed. Validate required input and permissions early, then normalize data, perform transformations, and review the result before any irreversible output.

The exact order depends on the task. For example, you may need to decode an input before validating its structure, but you should not send it externally before checking it. Keep side effects—emails, payments, record updates—late and explicit. Add a clear failure path and decide whether a retry is safe.

Test one valid input, one malformed input, and one repeated run. The workflow should fail visibly rather than silently producing partial output.

Start with the destination. A person reading a brief summary may want plain text or Markdown; a spreadsheet may need CSV; an API usually expects structured JSON; a document to print or share may need PDF. Do not choose a format solely because a workflow node makes it easy to produce.

Ask what the next step needs: field names, ordering, character encoding, layout, or editability. Test one realistic output in the receiving app. Include an empty result and a malformed input in your test, and define whether a retry should overwrite or create another output.

The workflow is finished only when its recipient can use the result without manual repair.

Keep the shape of your data, not its private values. Replace real names, emails, account numbers, tokens, addresses, and internal URLs with clearly fake examples. Remove fields unrelated to the failure.

Then run the example through the same workflow step to confirm it reproduces the behavior. If replacing a value makes the bug disappear, describe its relevant property—such as “contains a comma” or “is empty”—without revealing the actual value. Check screenshots, logs, metadata, and exported files for hidden identifiers before posting.

A safe example should still show the input, expected output, and actual output well enough for others to help.

Write down one complete manual run: what arrives, what you change, how you check it, and where the result goes. Identify steps that are rule-based and repeat often; keep ambiguous decisions as a review step.

Build the smallest version in Workflows using synthetic input. Define the expected output for a normal item, an empty item, and a malformed item. Then test a repeated run to see whether it creates duplicates or overwrites good data. Make errors visible and keep a way to stop before external actions such as sending or publishing.

Automate the reliable middle of the task first, not every judgment at once.