A Scenario That Fails Safely

What it is for

Every scenario has modules that must never run twice — a payment, a message, a write to a ledger. This covers error handlers and how to make a retry safe around exactly those.

The skill Copy

A scenario is easy to build and quiet when it breaks. Decide the failure
behaviour per module before adding the next one.

For every module, answer:
- **What if it runs twice?** Webhooks re-fire and scenarios retry. Any module
  that creates, charges, sends or posts needs a Search-before-Create, or a
  deduplication key stored somewhere the retry can see it. Without one, a retry
  sends a second invoice.
- **What if it fails halfway?** If modules 1–3 wrote and module 4 failed, the
  record is half-made. Either make the last module the only one that commits,
  or attach a rollback route.

Then, concretely:
- Attach an **error handler route** to every module that touches an external
  service. The default is "scenario stops", and a stopped scenario is silent.
- Use `Break` with a retry interval for transient failures and `Commit`/
  `Rollback` for anything transactional. `Ignore` is almost never right — it
  converts a failure into missing data.
- Route errors to somewhere a human reads. Make's own notification goes to the
  account owner's email and is routinely filtered.
- Turn on **sequential processing** for anything writing to the same record.
  Parallel bundles hitting one row is the bug that only shows up under load.

How to install it Copy

1. Open the tool and start a new conversation, project or template.
2. Paste the text below wherever the tool keeps standing instructions
   — usually called system prompt, instructions, or persona.
3. Save it so it applies to every run rather than a single message.

Did it work for you?

Where it came from