Error Handling

QuickFlo handles the common case for you: retry a temporary problem, stop on a lasting one, and preserve enough context to investigate the run.

When something fails, begin with the execution. Change retry settings only after you know what happened.

Start with the failed execution

Open Executions and select the run. Find the first failed step, then compare its input, output, and error.

Ask three questions:

1. Did the step receive the values you expected?
2. Did the external service return a useful response?
3. Is the problem temporary, or will the same request fail again?

A timeout may be worth retrying. A missing required field is not. A 401 usually means the connection needs attention, not more attempts.

Use Platform Logs when the symptom spans several runs or you need to see trigger activity around the same time.

What QuickFlo does by default

Steps that talk to external systems recognize common temporary failures such as timeouts, connection problems, and rate limits. QuickFlo retries those with a short delay.

If the step still cannot finish, the workflow stops and the execution is marked Failed. Steps that never ran remain visible as skipped.

Some services return a useful response even when the operation failed—for example, an HTTP 400 with a JSON explanation. QuickFlo keeps that response available in the execution so you can diagnose the real problem.

Tip

The default retry behavior is right for most workflows. Treat a custom retry policy as an exception you can explain, not a setup step every workflow needs.

Let a workflow continue

Turn on Continue on Error for a step only when later steps can produce a useful result without it.

Good examples include:

• optional enrichment after the required record has already loaded;
• sending one notification after another notification succeeds;
• trying a primary lookup before a deliberate fallback path.

When QuickFlo handles a failure this way, the execution can finish as Completed with errors. The failed step remains visible and its error is added to $errors.

Avoid enabling Continue on Error without a follow-up branch, alert, or fallback. Otherwise the workflow can look healthy while quietly dropping work.

Customize retries when the default is wrong

Open a step’s error settings and choose a retry behavior:

Setting	Use it when
Smart	The normal choice. Retry temporary failures and stop on permanent ones.
Aggressive	The provider is unreliable and repeating the operation is safe.
Rate limits only	You only want another attempt after throttling.
Custom	You know the provider’s error codes and need an explicit policy.

You can also change the maximum attempts and delay. Keep the smallest retry window that covers the provider’s normal recovery time.

Caution

Be careful when retrying operations that create, charge, send, or delete. Use the provider’s own duplicate-protection feature when it offers one. For a worked QuickFlo pattern, see Process an event once.

Warnings and partial results

Not every problem needs to stop the workflow. A step may return a warning when it produced a usable but incomplete result—for example, an AI agent reaching a limit after producing a partial answer.

Warnings appear in the execution and in $errors, but the workflow continues. A run that reaches the end with a warning is marked Completed with errors.

If a later step needs to branch on the result, read the step metadata:

{{ fetch-customer.$meta.success }}
{{ fetch-customer.$meta.error.message }}

Use those values for a small decision. For a multi-step recovery path, an If or Switch step is easier to read on the canvas.

Skip work that is not needed

Every step can have a Skip Condition. When the condition is true, QuickFlo marks the step as skipped and moves on.

Skip conditions are useful for one-step guards, such as sending a receipt only when an email address exists. If several steps share the same condition, put them inside an If branch instead.

A practical recovery pattern

For an optional provider lookup:

1. Keep Smart retry behavior.
2. Turn on Continue on Error.
3. Add an If step that checks whether the lookup succeeded.
4. Use the result on the success branch.
5. Record a fallback value or notify someone on the failure branch.

This keeps the exception visible without making the whole workflow depend on an optional service.

For organization-wide patterns, search Platform Logs by workflow, level, or error message. For one run, stay in Executions and follow the trace from the first failure.