Why it matters
Not every trigger event should follow the same path. Flow-control steps let a workflow stop cleanly, choose different branches, repeat work for multiple items, and handle step outcomes without moving complex logic into custom code.
Key Concepts
Filter Step: Continues only when its conditions pass; otherwise the run ends with a Filtered status.
Split in Paths: Creates multiple branches in the workflow.
Conditional Path: Defines the rules for one branch beneath a split.
Loop Step: Repeats its child steps for every item in a collection.
Error Path: A fallback branch that can run when a supported step fails.
Success Path: A branch associated with successful completion where supported.
Condition: A comparison used to decide whether a filter or path matches.
Collection: A list or array of items supplied to a loop.
Stop Unwanted Runs with a Filter
Use a filter when the workflow should continue only if defined criteria are met.
If the filter passes, downstream steps run. If it fails, Whippy stops the run without treating it as an error and marks the run Filtered.
Step-by-Step: Add a Filter
Add Filter Step after the step that supplies the data to evaluate.
Select the field from the variable picker.
Choose the comparison operator.
Enter or select the comparison value.
Add additional conditions if needed.
Save the filter.
Add the step that should run when the filter passes.
Test with one matching and one non-matching example.
Use a filter for a simple continue-or-stop decision. Use paths when different outcomes should take different actions.
Route Work with Paths
A path split contains multiple conditional branches. Each branch should describe a distinct case.
Step-by-Step: Add Conditional Paths
Add Split in Paths where the workflow should branch.
Add or open a Conditional Paths step beneath the split.
Name the path for the outcome it represents.
Select the field to evaluate.
Configure the path conditions.
Save the path.
Add the actions that should run on that branch.
Add and configure the remaining paths.
Test each path with representative data.
Make conditions mutually clear. Overlapping conditions can make the workflow harder to predict and troubleshoot.
Design Paths Carefully
For a simple classification, define paths such as:
Urgent: Priority equals Urgent
Standard: Priority equals Standard
Needs review: Required classification data is missing
A fallback path is useful when incoming values are incomplete or new values appear later.
Process Lists with a Loop
Use a Loop Step when an earlier step returns a collection and the same work should be performed for every item.
Examples include processing a list of contacts, attachments, search results, or records from an API.
Step-by-Step: Add a Loop
Add Loop Step after the step that returns the collection.
Select the collection to process.
Configure the loop.
Add the steps that should run for each item inside the loop.
Use the current loop item in those child steps.
Add any step that should run once after the loop outside the loop.
Test with a small collection.
Confirm the run details show the expected iterations.
Nested loops are not currently available. App actions may also be restricted in some loop positions; use the step picker at that location as the source of truth.
Add Steps Inside or Outside a Loop
Add a step inside the loop when it should run once per item.
Add a step outside the loop when it should run once after all items are processed.
For example, add one record-update step inside the loop, then one Slack notification outside the loop to report that processing finished.
Handle Errors
Supported actions can expose an error-handling option in the step menu. Use an Error Path when the workflow should log, notify, or recover from a known failure instead of ending immediately.
Step-by-Step: Add an Error Path
Open the menu on a supported action.
Add the available error handler.
Add the fallback steps beneath the error path.
Use available error information in those steps.
Test the failure behavior with safe input.
Confirm the workflow does not hide errors that still require attention.
Error paths should not silently discard important failures. Notify an owner or preserve enough information to investigate the problem.
Choose the Right Flow Control
Use Filter for continue or stop.
Use Split in Paths and Conditional Paths for two or more different outcomes.
Use Loop to repeat work across a collection.
Use Error Path for supported failure handling.
Use Wait when the workflow needs time to pass.
Use Wait For when the workflow must pause until an external result is available.
Tips and Best Practices
Name paths after business outcomes, not technical conditions.
Put the simplest, most specific conditions first.
Include a fallback for unexpected or missing values.
Test every branch separately.
Test loops with an empty list, one item, and several items.
Keep loop bodies small to limit repeated external calls.
Review API limits before placing HTTP or app actions in loops.
Use Filtered run status to distinguish intentional stops from failures.
Troubleshooting
Issue | Possible Cause | Fix |
A run ends as Filtered | The Filter Step conditions did not pass | Inspect the filter input and confirm whether the stop was intended |
The wrong path runs | Conditions overlap, use the wrong field, or do not cover the input | Review each condition with the actual run input and add a fallback path |
A path has no next step | The branch is incomplete | Add and configure the intended action under that Conditional Path |
A loop does not run | The selected value is empty or is not a collection | Inspect the previous step output and select the correct list field |
An action runs too many times | It was placed inside the loop | Move the action outside the loop if it should run only once |
A step cannot be added in a loop | That step or context is not supported there | Choose an available step or place the action after the loop |