Make.com scenario blueprint with error handling, rate limits, and operations budgeting

You are a Make.com automation architect who optimizes for reliability AND operations cost. Blueprint a scenario that [GOAL, e.g. syncs new form submissions to a CRM and Slack].

Return it as a numbered module list I can build step-by-step:

1. TRIGGER MODULE: App, event, webhook vs polling (and why), which fields to watch, and schedule interval recommendation.
2. EACH SUBSEQUENT MODULE: App, action, and exact field mapping from prior steps (use Make.com's {{N.field}} notation where possible). For data transformations, specify the exact Make.com function (e.g., `{{formatDate(1.created_at, "YYYY-MM-DD")}}`, `{{ifempty(1.phone, "N/A")}}`).
3. ROUTER placement: Place a Router BEFORE any Iterator to filter out irrelevant items early — this is the #1 operations-saving pattern. Specify each route's filter condition in Make.com syntax.
4. ERROR HANDLING — be specific about these patterns:
   - Webhook timeout: if a downstream API is slow, add a Sleep module (≤ 30s) or switch to async processing with a queue (data store). Specify the timeout threshold.
   - API rate limits: configure retry with exponential backoff — 1st retry at 60s, 2nd at 120s, 3rd at 240s. Show where to set this in the module's advanced settings.
   - Partial failures: use a Break error handler (not Ignore) so the scenario continues but logs the failure. Route failed items to a 'dead letter' data store for manual review.
   - Duplicate prevention: specify the dedupe key and WHERE to check it (data store lookup before the create/update module, not after).
5. DATA TRANSFORMATION PITFALLS to flag:
   - Date formats: APIs return ISO 8601 but the target might expect 'MM/DD/YYYY' — always use formatDate().
   - Empty arrays: an Iterator on an empty array consumes 1 operation and produces nothing — add a filter before it (`{{length(1.items)}} > 0`).
   - Nested JSON: when mapping from a webhook, specify the exact path (e.g., `{{1.body.data.attributes.email}}` not just `{{1.email}}`).
   - Number-as-string: APIs often return numbers as strings — use `{{parseNumber()}}` before math operations.
6. OPERATIONS BUDGET — make this concrete:
   - Calculate the expected operations per run (e.g., 'Trigger(1) + Router(1) + Filter pass(1) + 2 API calls(2) = 5 ops per item × ~100 items/day = 500 ops/day').
   - State which Make.com plan this fits within.
   - Give 2 specific optimizations: (a) 'Use an Aggregator after the Iterator to batch API calls if the target supports bulk create', (b) 'Move the dedup check to the Router filter to skip items before they consume module operations'.

For any HTTP module, specify: method, URL pattern, headers (especially Content-Type and Auth), and body shape as JSON. End with a 'Scenario Health' checklist: ✅ error handler on every API module, ✅ dedup before create, ✅ Router before Iterator, ✅ logging module for debugging.