Upcoming change: More consistent loop behavior when a step fails in conditional logic

At a glance:

Why we’re making this change

In Pipelines, errors typically stop a pipeline run. That’s a safe default: if something unexpected happens, the pipeline pauses, allowing you to review and fix the issue.

Loops are the notable exception. In many real-world automations, it’s better to keep going even if one item fails—especially when processing a list of records (like invoices or purchase orders).

Today, loops already behave that way:

• If one loop iteration fails, Pipelines usually skips that record and continues with the next one.

But we found an inconsistency:

• If an iteration includes conditional branching (IF/ELSE) and the logic step fails along that path, the entire pipeline run stops, rather than skipping just the one problematic iteration.

We’re updating Pipelines so that loop behavior is consistent, regardless of whether an iteration includes an IF/ELSE.

Learn more about conditions in our help article.

A quick refresher: How errors normally work in Pipelines Simple pipeline (no loop) Use case: When a new invoice is marked “Approved,” update a related project record. Example flow: Trigger: Invoice is updated (Status = Approved) Step: Find the related Project Step: Update Project “Invoiced Amount” If any step fails (for example, the Project can’t be found), the pipeline run will stop, and you’ll see the error in the activity log. Today, the HTTP channel is an exception because it provides more built-in options for handling responses and failures. We’re also planning improvements to error handling over time, so stay tuned. Loops: What happens when one record fails Loop without conditional branching (current behavior) Use case: Every night, process all “Ready to Pay” invoices. Example flow: Trigger: Scheduled (nightly) Step: Find invoices where Status = “Ready to Pay” Loop: For each invoice Update invoice status to “Submitted to Accounting” Write a note back to the invoice If there are 10 invoices and invoice #6 fails (maybe it was deleted, locked, or missing required fields): Pipelines will skip invoice #6 Continue processing invoices #7–#10 The run will not fail entirely The activity log will show which invoice failed and why This is the behavior many customers expect (and rely on) when automating batches of records.

The inconsistency we’re addressing

Loop with IF/ELSE branching (current behavior in some cases)

Now, let’s add a very common pattern: decisions as part of each loop iteration.

Use case: Nightly invoice processing with a rule:

• • If the invoice total is over $10,000, send it for additional approval
  • Otherwise, submit it to Accounting

Example flow:

1. 1. Trigger: Scheduled (nightly)
   2. Step: Find invoices where Status = “Ready to Pay”
   3. Loop: For each invoice
      • IF Total > $10,000
        • Create an “Approval Request” record
        • Notify an approver (email/Slack/etc.)
      • ELSE
        • Update invoice status to “Submitted to Accounting”

What can happen today:
If the condition step fails in a single iteration (for example, invoice #6 amount is missing), the pipeline run will stop completely—even though you still have invoices #7–#10 to process.

That’s inconsistent with how loops behave in other scenarios.

What this means for you

Most pipelines won’t require any changes. But the planned for February 10th change is especially relevant if you:

• • Use loops to process batches of records (invoices, purchase orders, requests, etc.)
  • Use IF/ELSE branching inside the loop to apply different actions per record
  • Expect the pipeline to continue even if one of its iterations fails

If you previously relied on the pipeline stopping in this scenario, consider adding a STOP step intentionally when you want that behavior.