Flow Lab

Make.com scenario rescue · demo case

Most runs looked fine. Leads were still slipping through.

A website quote form feeds a Make scenario: log the request, look up the service area, ping the on-call tech for urgent jobs, email sales for the rest. Most runs look fine in History. The audit found 11 problems, and 6 of them mean a lead gets no alert or arrives with blank fields.

Demo scenario built for this case, modeled on a typical home-services lead flow. Not a client's scenario.

11problems found: 9 by the automatic review, 2 in manual review
6of them: a lead gets no alert, or the alert has blank fields
0flagged by the same automatic checks after the fix

The scenario

What was wrong, and the fix

HIGH · lost leads

One failed step switched the whole scenario off

"Allow storing of incomplete executions" was off. If Google Sheets, Slack or Gmail hiccuped, the run stopped with an error and there was nothing to retry: the website never resends a form. Worse, with the default error settings Make deactivates a webhook-triggered scenario right after its first error, so every quote request after that was missed until someone noticed.

Fix: incomplete executions on, plus Break handlers with automatic retry on the Sheets, Slack and Gmail steps. A failed step now waits and retries instead of stopping everything.

HIGH · blank fields

API errors were treated as answers

The ZIP lookup (legacy HTTP module) had "Evaluate all states as errors" switched off. When the API returned 401 or 500, Make carried on with the error body as if it were the service area, and "Area:" in the alerts came out blank.

Fix: moved to the current HTTP "Make a request" module with "Return error if HTTP request fails" on, and a Resume handler that fills "area lookup failed, check ZIP", so the lead still reaches sales with a clear note.

HIGH · security

A live API key sat inside the module URL

Anyone who got the exported blueprint (a freelancer, a shared template) got the key with it.

Fix: key moved into a Make keychain (API key authentication in the HTTP module), so it never appears in an export, and the old key rotated.

HIGH · blank fields

Two fields pulled data from steps that never ran

The Slack alert showed "Quote #" from the Gmail module on the other route, and the sales email used a field from a module that had been deleted. Both always came out empty.

Fix: both now use the Google Sheets row number from the "Log request" step, which runs before the router on every path.

MEDIUM · noise and a gap

Sales got one email per service, or none at all

An iterator over "services" fed Gmail directly. A customer who ticked three services produced three near-identical emails. Found in manual review: a customer who ticked none produced no email at all, because an empty list gives the iterator nothing to pass on.

Fix: no iterator. The email lists the services with join() and says "not specified" when the list is empty: one request, always one email.

HIGH · found in manual review

"Urgent" didn't match "urgent"

The router filters used exact, case-sensitive matches for "urgent" and "standard". A form that sends "Urgent", or an empty value, matched neither route. The row was already in the sheet, but with no fallback route nobody was told about the lead.

Fix: case-insensitive match for "urgent", and the sales route became the fallback route: anything not urgent reaches sales.

LOW · housekeeping

Smaller settings

Sheets rows were written as plain text, so dates and numbers didn't sort or filter.

Fix: valueInputOption: USER_ENTERED.

Before and after

SituationBeforeAfter
Gmail or Sheets fails for a minuteRun fails, scenario switched offStep retried, scenario keeps running
ZIP API returns an errorBlank "Area", no warningLead sent with "check ZIP" note
Form sends "Urgent" (capital U)No route matches, nobody alertedOn-call tech alerted
Customer picks 3 services / none3 emails / no emailAlways 1 email
Quote reference in alertsAlways emptySheet row number
Exported blueprint sharedLeaks the API keyNo secrets inside

The audit report

The first pass is an automatic review of the exported blueprint: nothing runs, and no access to your accounts is needed. Then a manual review of the logic, and every item is checked in the editor before anything is changed. Excerpt:

Make scenario review: Quote requests -> Sheet -> Sales alerts (BEFORE)
7 modules, trigger: instant (webhook).

1. HIGH - Scenario settings: "Allow storing of incomplete executions" is off
   and the scenario starts with a webhook. When any module fails, the run
   stops and that request is gone. With default settings, Make deactivates
   an instant-trigger scenario immediately after its first error.
2. HIGH - "ZIP -> service area" [3]: "Evaluate all states as errors" is off:
   a 4xx/5xx reply counts as success.
4. HIGH - "Alert on-call tech" [5]: Maps a field from "Email sales" [7],
   which is not on the path before this module. Always empty here.
...
AFTER: No issues found by the automatic checks. (Manual review: done.)
Blueprint before (.json) Blueprint after (.json) Report before (.txt) Report after (.txt)

The blueprints are hand-written for this demo to show the structure of the fix and have not been imported into Make; module settings are illustrative. On a real job every change is made and tested in your own account.

How a rescue works

  1. You export the scenario: in the editor, … (More) → Export Blueprint, and send the .json file. No login needed for the first look.
  2. Same day: a plain-English list of what's broken, what it costs you, and what I'd change.
  3. You approve; I fix it in your account, run test submissions through every route and show you the results.
  4. Optional monthly support: I watch the scenario's errors and fix new ones before they cost you leads.