ericrisco Automation strategy — decide whether, where, and how before anyone builds
This is the discipline layer of the automation suite. It answers three questions that come before the first node is wired: should this be automated at all?, on what platform, and is a platform even the right tool vs code?, and what orchestration guarantees does every automation have to meet so the fleet doesn't rot? No platform API, no importable JSON, no code lives here — the moment the decision is made, you route to the skill that builds it.
Building the flow (design + importable artifact) → ../automation-flows/SKILL.md. Driving a specific platform's live API/MCP → ../n8n/SKILL.md, ../make/SKILL.md, ../zapier/SKILL.md, ../power-automate/SKILL.md. A typed API client in code → ../api-connector-builder/SKILL.md. Receiving webhooks in your own app → ../webhooks/SKILL.md.
Every fact about pricing and platform capability below moves fast. Treat the ≈ figures as hedges and re-check the vendor page at author time; the honest limits (Zapier can't create Zaps via public API; Power Automate can't create end-user "My flows" cleanly via API) are called out where they matter and expanded in the references.
1. Should you automate at all?
Most "we should automate this" instincts are wrong — not because automation is bad, but because the process underneath isn't ready, or the payoff isn't there. Gate on four factors, all of them, before writing a line:
- Frequency — how many times per week/month does this run? A once-a-quarter task rarely earns its maintenance cost.
- Time saved per run — minutes of human toil removed each time. Two minutes × 1,000 runs beats an hour × 3.
- Error rate of doing it by hand — high manual error rate (typos, missed steps, missed SLAs) is often a bigger win than the time saved. Automation's real product is consistency, not just speed.
- Stability of the process — how often do the steps, the systems, or the rules change? An unstable process is the one thing that turns automation into a liability.
Rough gate: automate when it is frequent AND stable AND either saves meaningful time-per-run or removes a costly manual error rate. If it's frequent but unstable, or high-value but requires judgment on every run, do not automate yet — see below. Full scoring rubric with worked numbers: references/automate-decision-and-roi.md.
The trap: automating a broken or unstable process
Automating a bad process just makes you produce bad output faster, and now nobody can see the badness because a machine hides it. Fix and standardize the process first, then automate the standardized version. If the steps aren't written down the same way twice, if it "depends", if three people do it three ways — you are not ready. Standardize on paper, run it manually a few times against the written steps, then encode it. Automating chaos gives you automated chaos with a maintenance bill.
Human-in-the-loop: what you deliberately do NOT fully automate
Some steps should stay manual by design, wrapped in an approval gate rather than removed:
- Judgment calls — pricing exceptions, hiring decisions, content that carries brand/legal risk, anything where "usually right" isn't good enough.
- Irreversible or high-blast-radius actions — sending money, deleting data, emailing your whole list, publishing publicly, terminating accounts. Automate the preparation, require a human click for the commit.
- Low-frequency, high-stakes — the payoff is small and the cost of a silent wrong run is huge.
The pattern is assisted, not autonomous: the automation gathers, drafts, and stages; a human approves the commit. Cheap insurance against the day the automation is confidently wrong at scale.
2. ROI and build-vs-buy
Payback math
build cost = hours to build × loaded hourly rate
monthly saving = (runs/month × time saved per run × loaded rate)
− monthly platform/run cost
− monthly maintenance cost ← the line people forget
payback (months)= build cost / monthly saving
Two rules of thumb: if payback > ~12 months, the process is probably too rare or too cheap to bother; if maintenance eats > ~30–50% of the gross saving, you've built a pet, not a tool. Maintenance is not optional — APIs change, auth expires, edge cases surface. Budget it explicitly or the ROI is fiction. Worked examples: references/automate-decision-and-roi.md.
No/low-code platform vs custom code
| Choose a no/low-code platform when… | Choose custom code when… |
|---|---|
| Gluing 2–8 SaaS apps with pre-built connectors | Logic is genuinely complex, algorithmic, or stateful |
| Business owner needs to read/edit the flow | High volume where per-run platform billing dominates TCO |
| Speed to first version matters more than control | You need version control, tests, code review, CI on the logic |
| Volume is modest and connectors exist | The vendor has no connector and you need deep API control |
The honest middle: platforms win on time-to-first-version and readability; code wins on complex logic, testability, and cost at scale. Many mature setups are hybrid — a platform orchestrates and a small custom service (or api-connector-builder client) does the hard part.
Total cost of ownership
TCO is not the sticker price. Count: the platform bill under your real volume and its billing unit (this is where surprises live — see §3), build time, ongoing maintenance, the cost of an outage when it fails silently, and the switching cost if you outgrow the platform. A "free" automation that a senior engineer babysits monthly is not free.
3. Platform selection
Pick on billing unit first — it's the axis that dictates cost at scale, and choosing on familiarity instead is the classic 10× mistake. Then filter on data residency, ecosystem, programmatic maturity, and portability. This is a routing decision: once chosen, hand off to that platform's skill.
| Axis | n8n | Make | Zapier | Power Automate |
|---|---|---|---|---|
| Billing unit | per execution (whole run = 1, any # of steps); self-host = $0 | per credit (each module action = 1; was "operations", renamed 2025-08-27) | per task (every action counts) | per user or per flow (premium); bundled with many M365 plans |
| Best cost shape | few long/complex flows, high volume | moderate multi-step flows | many short simple flows | teams already paying for M365 |
| Self-host / data residency | yes — your infra, your data | no (EU/US regions only) | no | Microsoft cloud / Dataverse regions |
| Ecosystem fit | technical teams, raw HTTP, code nodes | mid-market, deep per-app modules | widest app catalog (~9,000+) | native to Microsoft 365 — Teams, SharePoint, Outlook, Dataverse |
| Programmatic + MCP maturity | public REST API to CRUD workflows; community MCP; strongest for code-driven ops | management API + MCP support maturing | rich API for actions + Zapier MCP to expose actions to agents — but no public API to create Zaps | Flow management APIs + solutions/ARM — but no clean public API to create end-user "My flows" |
| Portability | high — export/import JSON + self-hostable runtime | medium — blueprint export/import, but runs only on Make | low — no portable export | low — tied to MS solutions |
Routing shortcuts: already living in Microsoft 365 → Power Automate (../power-automate/SKILL.md). Data must stay on your own infra, or high volume where execution-billing wins → n8n (../n8n/SKILL.md). Obscure app, non-technical owner → Zapier (../zapier/SKILL.md). Deep per-app modules, mid volume → Make (../make/SKILL.md).
Two capability limits to state honestly, not paper over: you can drive Zapier's actions programmatically and via MCP, but you cannot create a Zap through a public API — Zap authoring is UI-only. Power Automate exposes flow management and solution deployment, but there is no clean public API to author an end-user's personal "My flows". If a plan depends on API-creating either, the plan is wrong. Full matrix, MCP notes, and caveats: references/platform-selection-matrix.md.
4. Orchestration strategy (engine-agnostic)
These are the guarantees every automation must meet regardless of platform. This is the policy; the per-platform recipe lives in ../automation-flows/SKILL.md and the platform skills. Deep dive: references/orchestration-and-antipatterns.md.
- Idempotency & dedup. Delivery is at-least-once and retries replay; assume every event can arrive twice. Require a stable dedup key (event id / external id) checked before any non-idempotent write (charge, email, insert). No dedup on a non-idempotent write = duplicate charges waiting to happen.
- Error paths, retries & backoff. Every automation has a defined destination for failure. Retry transient errors (timeouts, 429/5xx) with backoff and a cap; do not retry permanent errors (400/validation) — route them out. A flow with no error path isn't finished.
- Dead-letter. After retries are exhausted, the failed item lands in a durable place a human can inspect and replay — a queue, a table, an "incomplete executions" store. Dropped-on-the-floor failures are invisible data loss.
- Observability & alerting. Emit success/failure counts; put a heartbeat on scheduled jobs and alert on silence (a cron that stops firing is the failure you never hear about). Route alerts to a named owner, not a dead inbox.
- Secrets handling. Credentials in the platform's credential store / a vault, referenced by name — never pasted inline where an export leaks them. Least privilege, and a rotation plan. Engineering detail →
../secure-coding/SKILL.md. - Versioning & environments. Separate dev/staging from prod; export before you edit; keep a rollback. Changes to a live automation are production changes and deserve the same care.
- Avoid fan-out storms. Cap concurrency, batch, and rate-limit. Watch for echo loops (flow A writes a record that triggers flow B that triggers flow A) and for a single event fanning out into thousands of downstream calls that trip rate limits or blow the bill.
5. Anti-patterns
| Anti-pattern | Why it bites | Do instead |
|---|---|---|
| No error path | First API hiccup, the run dies; you learn from an angry customer | Define a failure destination + alert before shipping |
| Silent failure | Failures that don't alert erode trust worse than no automation — everyone assumes it worked | Alert on failure and on silence (heartbeat) |
| No kill-switch | When it misfires at scale, there's no fast way to stop the bleeding | Every outward-writing automation gets a documented pause/disable toggle |
| Over-automation | Automating rare / low-value / judgment work costs more to maintain than doing it by hand | Gate on §1; leave judgment steps human-in-the-loop |
| Automating a broken process | You produce bad output faster and hide the badness behind a machine | Standardize the process first, then encode it |
| Hidden single point of failure | One personal token / one undocumented flow everyone depends on | Service accounts, documented dependencies, no personal-account glue |
| No owner | Orphaned automations rot; nobody notices the break or knows how it works | Name an owner + a one-page runbook per automation |
| Choosing platform by familiarity | Bill 10× higher than the right billing unit; "our automation bill exploded" | Pick by billing unit for your run shape (§3) |
Checklist
- Ran the §1 gate: frequency × time-saved × error-rate × stability — and confirmed the process is standardized, not chaos being paved.
- Identified any judgment / irreversible / high-blast-radius step and kept it human-in-the-loop with an approval gate.
- Computed payback including maintenance, and confirmed it's under the rule-of-thumb ceiling.
- Decided platform vs custom code on the build-vs-buy criteria, not on what's familiar.
- Chose the platform by billing unit for the real run shape, then data residency / ecosystem / portability — and did NOT assume a capability the platform lacks (Zap creation, PA "My flows").
- Specified the orchestration guarantees §4 requires (idempotency key, error path, dead-letter, heartbeat/alert, secrets store, dev/prod split, fan-out caps) as requirements handed to the build skill.
- Every automation has a named owner, a runbook, and a kill-switch.
- Routed the actual build to
automation-flows/ the chosen platform skill — no flow was built inside this skill.