Handle Partial Batch Failures v2

Check each returned record when a Node reports individual write outcomes. A successful Step does not necessarily mean that every record in its batch was accepted.

Example: FreshBooks client writes

The FreshBooks Create, Update, and Delete Methods return a Response Array. Each mutation result includes Flowgear.IsSuccess, Flowgear.Message, and Flowgear.Request. The request contains the corresponding input item, including its nested client payload.

Suppose a Create Step named createClients receives two client items. One is accepted and the other is rejected. The following illustrates the metadata you need to inspect; the provider payload and diagnostic text are omitted:

[
  {"Flowgear":{"IsSuccess":true,"Request":{"client":{"email":"accepted@example.com"}}}},
  {"Flowgear":{"IsSuccess":false,"Request":{"client":{"email":"rejected@example.com"}}}}
]

This is an illustrative result shape, not a request to send to FreshBooks or a guarantee that these email values cause those outcomes.

Process each outcome

  1. Add a For Each Step after createClients and name it checkClients.
  2. Map its Items to {createClients.Response} and retain the nested Flowgear schema from the Method's Returns.
  3. Add an If Step inside the loop. Set its Expression to {checkClients.Items.Flowgear.IsSuccess}.
  4. Record the target identifier or completion marker in the true branch only after the provider result confirms success.
  5. Record a retry or investigation item in the false branch, using Flowgear.Request to correlate the failed input and Flowgear.Message for diagnosis.

The loop consumes the deferred response and ensures that later input items are processed. Inspect both branches in Debug using an approved Test Connection and disposable records. A useful test batch includes a valid record and a deliberately invalid record appropriate to your account's validation rules. Confirm that the successful write is recorded once and that the failed input reaches the investigation path.

You can also select failed rows for a downstream Array Parameter with:

FILTER({createClients.Response}, {createClients.Response.Flowgear.IsSuccess} == false)

This Expression supplies complete result rows. Map each selected row's Flowgear.Request when a retry operation expects the original input shape. Do not map the complete result envelope directly into Create.Items.

Retry deliberately

Correct the cause of failure before resubmitting failed inputs. Avoid replaying the entire batch: successful creates can be duplicated. A timeout or lost response can also leave an uncertain outcome even when the provider committed a change. Reconcile that record by a stable identifier, or use provider-supported idempotency, before retrying.

Keep Try/Catch around operations that can still raise exceptions. A later deferred failure may occur after earlier records have already been written; handling the exception does not undo those writes.

Request copies and error messages can contain personal or confidential data. Apply Workflow Log Redaction and store only the fields needed for recovery.

See also