Felix Bauer·
Before I build any Make scenario I have GPT-4.1 write the blueprint first: modules, error handlers, retry logic. Build time dropped from an afternoon to under an hour.
Turns a plain-language automation idea into a build-ready Make/Zapier blueprint with module list, data mapping, error handling, and a test plan.
No-Code Scenario Blueprint
You are an automation architect who designs Make.com scenarios before they are built. Your blueprints are what I follow while clicking — so they must be precise about modules, mapping, and failure paths, not vague about 'connecting the apps'.
Trigger event: {{trigger}}
Apps involved: {{apps}}
What should exist at the end, in plain language: {{desired_outcome}}
Volume estimate (runs per day): {{volume}}
Produce the blueprint in this structure:
1. **Scenario summary** — one sentence, then a linear module list numbered in execution order, each with: app, module name as it appears in Make, and its single job.
2. **Data mapping table** — for every field that crosses between apps: source module and field, destination field, and any transformation (formatting, fallback value, type coercion). Mark fields that can legitimately be empty and what happens then.
3. **Branching** — where a router is needed, the filter condition on each route, written exactly as it would be entered (field, operator, value).
4. **Failure design** — for each module that talks to an external service: what realistically fails (auth, rate limit, missing record), and the handler: retry with break, ignore, or rollback + notification. State where a duplicate run would cause damage and how to make the scenario idempotent (search-before-create, or a dedupe key field).
5. **Cost check** — estimated operations per run and per month at my stated volume; flag any module that multiplies operations on arrays.
6. **Test plan** — three test cases: the happy path, the most likely bad input, and the failure that would silently corrupt data if unhandled.
If my described outcome is better served by fewer modules or a native integration, say so before designing the complicated version.
Ergebnisse
## Blueprint: Invoice email → bookkeeping + client folder
**Summary:** When an invoice PDF arrives in the shared inbox, extract its data, create a draft entry in the accounting tool, file the PDF in the client's Drive folder, and post a confirmation to Slack.
**Module list:**
1. Gmail — *Watch Emails* (query: `has:attachment label:invoices`, folder: INBOX)
2. Gmail — *Get Attachment* (iterates; see cost note)
3. PDF.co — *Parse Invoice* (template: standard EU invoice)
4. Tools — *Set Variables* (normalize amount + date formats)
5. Router (2 routes: known client / unknown client)
6a. Xero — *Search Contacts* → *Create Draft Bill*
6b. Slack — *Post Message* to #bookkeeping (unknown sender, manual review)
7. Google Drive — *Search Folder* → *Upload File* (client folder)
8. Slack — *Post Message* confirmation with bill link
**Data mapping (key rows):**
| Source | Destination | Transform |
|---|---|---|
| PDF.co `total` | Xero `Amount` | `parseNumber(...; ",")` — EU decimal comma; fallback: route to 6b if empty |
| PDF.co `invoiceDate` | Xero `Date` | `formatDate(...; YYYY-MM-DD)`; fallback: email received date, flagged in bill reference |
| Gmail `from` | Router condition | domain-extract via `split(...; "@")` |
**Branching:** Route A filter: `6a.searchResults` → *Total number of bundles* → *Greater than* → `0`. Route B: fallback route (checkbox), not a mirrored condition — mirrored conditions rot when the search module changes.
**Failure design:** PDF.co parse failure (scan-quality PDFs, ~5% realistic): error handler *Ignore* + Slack alert with message link — never retry, same input fails identically. Xero rate limit: *Break* with 3 retries, 10-min interval. **Idempotency risk:** rerunning the scenario re-creates bills. Fix: step 6a searches for existing bill by `Reference = invoice number` first; create only when zero results.
**Cost check:** 8–10 ops per run; at your 15 invoices/day ≈ 4,500 ops/month — within the Core plan. Warning: *Get Attachment* iterates over ALL attachments; a signature image counts. Add a filter: filename ends `.pdf` AND size > 20 KB.
**Test plan:** (1) clean invoice from known client → draft bill + filed PDF + Slack link. (2) invoice with comma decimal and no invoice number → lands in manual-review route, not a half-created bill. (3) duplicate email forwarded twice → second run finds existing reference, creates nothing.
Modell: GPT-4.1
19 Likes13 SavesScore: 14
1 Kommentar
Chloe Adams·
The fallback-route-instead-of-mirrored-condition tip alone is worth the save. I have debugged that exact rot twice this year.