Felix Bauer·
I describe an automation in plain German or English, this returns a Make scenario blueprint with modules, mapping and error handling. Built our invoice pipeline from it in an afternoon.
Converts a plain-language process description into a complete Make scenario design with modules, data mapping, filters, and error handling.
Plain-Language to Make.com Scenario Blueprint
You are a Make.com (formerly Integromat) automation architect. Turn my plain-language process description into a buildable scenario blueprint.
Process description:
{{process_description}}
Apps we use: {{app_stack}}
Volume: {{volume}} (e.g. 30 invoices/week)
What absolutely must not happen: {{failure_constraints}} (e.g. duplicate entries, lost attachments)
Produce the blueprint in this structure:
1. **Scenario summary** — one sentence, plus the trigger type (instant webhook vs. scheduled polling) with reasoning. Prefer instant triggers when the app supports them; state the polling interval and its cost in operations if not.
2. **Module chain** — numbered list. For each module: app + exact module name as it appears in Make, what it does, and the key field mappings written as `target_field <- source (transformation)`. Show real Make functions in transformations (parseDate, split, ifempty).
3. **Filters and routers** — where the flow branches, the exact filter conditions, and what happens on each route.
4. **Error handling** — for each module that can realistically fail: the error type, the handler to attach (retry with break, resume, rollback, ignore), and dead-letter behavior (e.g. log to a Google Sheet + Slack alert with the bundle payload).
5. **Idempotency** — how we guarantee re-runs do not create duplicates (search-before-create module, unique key, or data store), given my failure constraints.
6. **Ops estimate** — operations consumed per run and per month at my volume, and the single change that would reduce it most.
If my description is ambiguous at any decision point, list the assumption you made inline as [ASSUMED: ...] and continue — never stall.
Ergebnisse
## Scenario: Invoice intake — Gmail to Sheets + Slack
**Summary:** Watch a Gmail label for supplier invoices, extract PDF data, log to Google Sheets, notify #finance. Trigger: **Gmail > Watch emails** (polling, 15 min) — Gmail has no instant trigger in Make; 15 min costs ~2,880 ops/month idle but meets your "same business day" requirement. [ASSUMED: same-day processing is fine, real-time not needed for invoices.]
### Module chain
1. **Gmail > Watch emails** — label `invoices/incoming`, mark as read after processing.
2. **Iterator** — iterate attachments (an email can carry several PDFs).
3. **Filter inline:** `filename` ends with `.pdf` AND `size > 10kb` (skips signature images).
4. **PDF.co > PDF Parser** — extract fields with your invoice template.
- `invoice_number <- body (regex template field)`
- `amount <- total (parseNumber(total; ","))`
- `invoice_date <- date (parseDate(date; "DD.MM.YYYY"))`
5. **Google Sheets > Search rows** — search `invoice_number` in column B. **This is the idempotency gate.**
6. **Router:**
- Route A (no match): continue to 7.
- Route B (match found): **Slack > Create message** to #finance — "Duplicate invoice {{invoice_number}} received again" — then stop. Nothing is written twice.
7. **Google Drive > Upload file** — folder `/Invoices/2026/`, name `{{invoice_number}}_{{supplier}}.pdf`.
8. **Google Sheets > Add a row** — `[invoice_number, supplier, amount, invoice_date, drive_link, now]`.
9. **Slack > Create message** — #finance: "New invoice {{invoice_number}} from {{supplier}}: CHF {{amount}} — {{drive_link}}".
### Error handling
- **Module 4 (PDF parse fails — scanned/no text layer):** attach *Resume* handler with empty values → Router sends it to a manual-review route: upload raw PDF to Drive `/Invoices/manual-review/` + Slack alert "Invoice needs manual entry". Nothing silently dropped.
- **Module 7/8 (Google quota errors):** *Break* handler, 3 retries, 10-min interval — transient quota errors self-heal.
- **Dead letter:** scenario-level: incomplete executions ON, so failed bundles are replayable from the Make UI.
### Idempotency
Search-before-create on `invoice_number` (module 5) satisfies "no duplicate entries ever." Re-running a failed execution re-hits the gate and exits via Route B.
### Ops estimate
Per invoice: ~7 ops. At 30 invoices/week + polling overhead: **~3,700 ops/month** — comfortably inside the Core plan. Biggest reduction: move polling to 30 min (saves ~1,400 ops) if same-half-day is acceptable.
Modell: GPT-4o
13 Likes8 SavesScore: 10
1 Kommentar
Chloe Adams·
The search-before-create gate is the piece every homegrown automation is missing until finance asks why an invoice was paid twice.