AutoProbaho

Checklist

Automation project checklist: before, during and after the build

Most automation failures are not technical. The trigger was fuzzy, the exceptions were never listed, nobody owned the data it read, or the workflow ran perfectly for a year and then failed silently because nobody was watching. This checklist walks through what to settle before you build, what to verify while you build, and what must be in place before an automation is allowed to run unattended.

Book a free consultation

Three moments that decide whether an automation lasts

Before the build: is the process worth automating, are the rules clear, and is the data it depends on owned and clean? During the build: is it tested against real, messy cases and does it fail loudly? After go-live: does someone receive its errors, hold its credentials and review it when a connected system changes?

The checklist below is grouped by those three moments. It is deliberately short on platform specifics — the same questions apply to n8n, Zapier, Make and custom integrations.

How to use this checklist

Use it per automation, not per project. A portfolio of ten workflows should have ten completed checklists, each with a named owner. Keep the completed list with the workflow's documentation; it becomes the first thing a colleague reads when something stops working.

  • The process is worth automating: it is frequent, rule-based and its failures are visible and costly
  • The trigger is precisely defined — which event, in which system, with which conditions
  • The steps are written down in plain language a new employee could follow by hand
  • The exceptions are listed — missing data, duplicates, unusual formats, out-of-hours cases — and each has a defined handling
  • The system that holds the master version of each piece of data the automation reads or writes is agreed
  • The data the automation depends on has been cleaned to the extent it needs (names, codes, units, formats)
  • The platform is chosen deliberately — hosted tool, self-hosted n8n or custom code — based on volume, data control and who will maintain it
  • Credentials and API access are set up under a shared or service account, not a personal login
  • The workflow has been tested with real cases including the ugly ones — not only the happy path
  • Failures are loud: errors land in a defined place (queue, channel, digest) that a named person watches
  • The automation has run in parallel with the manual process for a short, defined period and results were compared
  • Retry and idempotency behaviour is defined so a re-run does not create duplicate orders, messages or postings
  • Any AI step has a human review point wherever a mistake would cost money or trust
  • The automation is documented in plain language: what it does, which systems it touches, where its errors appear
  • A named owner holds long-term responsibility — monitoring, credential renewal, small fixes — internally or via managed support
  • The automation is in a shared inventory alongside the others, with owner, dependencies and last-review date
  • A quarterly review is scheduled to retire, extend or re-prioritise automations from the original process map

Frequently asked questions

Yes. The platform changes how you build, not what you must decide: a clear trigger, listed exceptions, owned data, real-case testing, visible errors and a named owner. Those items are the same whether the workflow lives in n8n, a hosted tool or custom code.

Related solutions

Related services

Related industries

Case Studies

Starting an automation project?

Book a free consultation. We will help you scope the trigger, the exceptions and the data, choose the right platform honestly, and set up the error handling and ownership that keep automations running.

Book a free consultation Open the consultation calendar