What to prepare before automating a workflow

Keep it to one workflow

Automation tools describe a workflow as a trigger followed by steps. The n8n tutorial, for instance, builds a flow that starts on a schedule, fetches Berlin weather data from the Mockingbird sample API, uses an Edit Fields step to format the city, temperature and condition into a short report, and saves that report in a data table. It then has you run the workflow with Execute workflow and check the inserted row before you publish. The weather comes from a sample API, so treat it as practice data and not as a live measurement. Whatever tool you use, that shape is a useful discipline: one start, a few clear steps, a test before it goes live.

The mini-brief to copy

Paste these lines into a document and fill in each one in a sentence or two.

• Trigger: the single event that starts it (for example, a new form submission).
• Inputs: each field needed, where it comes from, and which are optional.
• Decisions: each rule as if/then, in the order checked.
• Outputs: what is created or sent, to whom, and in what format.
• Owner: one named person who fixes problems and approves changes.
• Errors: what happens if a field is missing or a step fails, and who is told.
• Duplicates: how you recognise the same item arriving twice.
• Test cases: five or more made-up examples with the expected result.
• Stopping point: the step where a person reviews before anything is sent.

Plan for errors and duplicates

Malformed or missing input can break a workflow. Decide in advance what counts as incomplete, whether to hold the item for a person, and which field identifies a repeat, such as a unique submission or event identifier. The same email address can send different, legitimate requests, so email alone is not a safe way to spot duplicates. A quiet failure that nobody sees is worse than a visible one.

Test with synthetic cases

Write fake examples before connecting any real data: a normal one, one missing a field, a duplicate, an unusually long message, and one that fits no rule. Use synthetic data, and use sandbox or tightly scoped test credentials stored securely. Never use production secrets or customer data while testing. Run the cases manually and compare the results with what you wrote down.

Set a safe stopping point

Begin with the automation preparing a draft or a suggested label, and have a person approve it. Only remove that step once the test cases and some careful review show the rules hold up.

A hypothetical example

Imagine routing a sample enquiry: "Hello, I need a quote for a booking system for my studio." The trigger is a new form entry. Inputs are name, email and message. The rule says that if the message mentions booking or app, label it Software, otherwise General. The output is a draft internal note to the owner, who approves it. A duplicate is a repeat of the same submission identifier; the same email with a different request is a separate enquiry. This is a planning illustration, not something tested or deployed.