Draft — in editorial review, not yet published. Content has not been approved by a human reviewer.

Lesson 11 / 50 · Version 2.2.0

Automation Architecture 101

Level: Beginner
Duration: 15 min learn + 15 min apply
Prerequisites:: None

Why it matters: Most failed automations fail on design, not tools: no clear outcome, no failure path, no owner. A one-page architecture written before you open Make, n8n, or Zapier prevents most of it.

By the end you can:

Describe any workflow as trigger, data, logic, action, and outcome
Compare polling and event-driven triggers
Map fields from source to destination
Define a success condition and an exception path

Learn (15 min)

1. The workflow pattern (5 min)

Every automation answers eight questions:

Element	Question	Example (booking → CRM)
Trigger	What starts it?	New booking confirmed
Input data	What arrives?	Name, email, service, date
Validation	Is it usable?	Email format valid, consent = yes
Decision	Which path?	Team session vs. individual
Action	What happens?	Create CRM contact; notify staff
Success condition	How do we know it worked?	One correct CRM record with an owner
Failure route	What if it breaks?	Send to review queue; alert owner
Owner	Who is responsible?	Operations lead

The goal is a correct, assigned CRM record, not "the workflow ran."

2. How triggers start work (5 min)

Polling: the platform checks a service every N minutes. Simple and works without webhooks; adds delay and repeated checks.
Event-driven (webhook): the service calls you when something happens. Fast, but you need a reachable endpoint, sender verification, and duplicate handling (Lesson 16). What's available depends on the app and your plan.

3. Data flow and boundaries (5 min)

Map every field: source name → destination name → transformation → required? Copy only what you need. Keep credentials in the platform's secure connection storage, never in field values or notes. Put permission checks and business rules in trusted systems. Set limits on retries, run time, and records per run.

Apply (15 min)

Worked example (3 min).

Trigger:     Booking tool "invitee created"
Validate:    email present; phone optional; consent checkbox = true
Transform:   "Team Headshots – 10 ppl" → service = "Team", headcount = 10
Branch:      service = Team → pipeline "Corporate"; else → "Individual"
Actions:     (1) search CRM by email → update or create contact
             (2) create deal in correct pipeline, owner = round-robin
             (3) Slack/email alert to owner
Success:     contact + deal exist and are associated; owner assigned
Exception:   missing email → "Needs review" sheet + alert

Lab (7 min): Draw your own.

Choose one real workflow you do by hand weekly.
Fill in the eight-element table for it.
Add a field-mapping table (source → destination → transform).
Mark one thing that could go wrong and the route it takes.

Deliverable: A one-page architecture (two tables). You're done when: A teammate could build it without asking you questions.

Check yourself (5 min)

What is a trigger?
Polling vs. event-driven in one line each?
Scenario: The run history is all green, but half the CRM records have no owner. What was missing from the design?
Where should an API key live?
A required field is missing. What should the workflow do?

Reference

Common mistakes

Symptom	Likely cause	Fix
Green runs, bad data	Success = "ran"	Define outcome-based success
Silent loss of records	No failure route	Add exception queue and alert
Secrets in notes	No credential discipline	Use platform credential store

Cheat sheet: Trigger → validate → transform → branch → act → verify → log/recover.

Key terms: trigger, payload, transformation, success condition, exception path, polling, webhook.

Interview prompts: How do you decide between polling and webhooks? What's in your design before you build?

Go deeper: n8n docs · Make module types · Zapier: set up a Zap action

Next: Lesson 12 — build it in Make.