Why it matters
The workflow builder is where you define what starts an automation, what actions happen next, and how Whippy should handle branching logic, filters, loops, waits, and errors. Building workflows carefully helps prevent failed runs, duplicate work, and unexpected automation behavior.
Use this article after you have created a workflow. For the workflow list, publishing status, and general workflow management, use Workflows in Whippy. For runs, versions, replay, and import/export, use Monitor and Troubleshoot Workflows in Whippy.
Key Concepts
Canvas: The visual builder where workflow steps are connected.
Trigger: The first step in the workflow. It defines what starts the automation.
Action: A step that performs work, such as sending an HTTP request, running code, or formatting data.
App Step: A step that connects to a supported app or Whippy integration.
Flow Control: A step that changes how the workflow moves forward, such as filters, paths, loops, or waits.
Variable: A value from an earlier step that can be used in a later step.
Test: A tool used to check a trigger, action, app step, or flow-control step before publishing.
Validation: The checks Whippy runs before a workflow can be published.
Step-by-Step: Start Building a Workflow
Open Workflows.
Create a new workflow or open an existing workflow.
If the workflow opens in the current view, click Edit workflow.
Click the empty trigger slot or an existing empty step.
Choose the type of step you want to add.
Configure the step in the panel that opens.
Save or move to the next tab in the panel.
Add additional steps until the workflow matches the process you want to automate.
Click Publish when the workflow is ready to go live.
Choose a Trigger
Every workflow needs a trigger. Whippy supports the following trigger types in the builder:
Webhook Request: Starts the workflow when Whippy receives a webhook request.
Email Parser: Starts the workflow from parsed email content.
Schedule (Cron Expression): Starts the workflow on a schedule.
Supported app trigger: Starts the workflow from an event in a connected app, when the app supports workflow triggers.
Step-by-Step: Configure a Trigger
Click the empty trigger slot.
Choose the trigger type.
Complete the Setup tab.
Complete the Configure tab when configuration fields are shown.
Use the Test tab to confirm the trigger sample or schedule works as expected.
Save the trigger.
Add the next step in the workflow.
For webhook and email parser triggers, use sample data where available so later steps can reference real fields from the trigger payload.
Add Steps to a Workflow
When you add a step, the builder shows the step types that are valid in that location. Available step options can change depending on whether you are adding a step after a trigger, inside a loop, inside a wait step, or under a path.
Common step groups include:
Apps: Connect to supported apps and integration actions.
Actions: Add HTTP Request, Run Code, or Formatter steps.
Flow controls: Add paths, filters, loops, waits, and wait-for logic.
Step-by-Step: Add a Step
Click the plus point or empty step where the next step should be added.
Search for the step type or browse the available groups.
Select the step.
Choose whether the step should be added inside or outside the current context when Whippy shows that option.
Click the step to open its configuration panel.
Complete Setup, Configure or Config, and Test where available.
Save the step.
Action Steps
Action steps are useful when the workflow needs to transform data or call another service.
Whippy includes these action step types:
HTTP Request: Send a request to an external API.
Run Code: Run a code step as part of the workflow.
Formatter: Format or transform values so later steps can use them.
Step-by-Step: Configure an Action Step
Add an action step.
In Setup, choose the action type.
In Configure, complete the required fields for the action.
Use variables from previous steps when the action needs dynamic data.
Open Test.
Click the test button, such as Test HTTP Action, Run Code Step, or Test Formatter.
Review the test response and console output.
Save the step.
App Steps
App steps connect a workflow to Whippy-supported apps and integration actions. Depending on the app, you may need to choose an account, sign in, select an action event, and complete app-specific fields.
Step-by-Step: Configure an App Step
Add an app step from the step picker.
In Setup, choose the app.
Select or connect the account Whippy should use.
Choose the app action or event.
Open Config.
Complete the required fields.
Use variables from previous steps when the app needs dynamic values.
Open Test.
Run a test and review the response.
Save the step.
If an app requires credentials, make sure the connected account has access to the records or actions the workflow needs.
Flow Control Steps
Flow control steps determine what path the workflow should take and when it should continue.
Whippy includes these flow-control options:
Split in Paths: Split the workflow into multiple paths.
Conditional Paths: Define the rules for a specific path.
Filter Step: Continue only when filter conditions are met.
Loop Step: Repeat steps over a collection of items.
Wait Step: Delay the workflow or wait based on conditions.
Wait For Webhook: Pause until a webhook response is received.
Wait For Polling: Pause while Whippy checks for an expected result.
Wait For Webhook and Polling: Use both webhook and polling behavior in the wait process.
Step-by-Step: Add Branching Logic
Add Split in Paths where the workflow should branch.
Add or open a Conditional Paths step.
Define the conditions for that path.
Save and validate the path.
Add the steps that should run when that path is matched.
Repeat for each path the workflow needs.
Step-by-Step: Add a Filter
Add a Filter Step after the step that provides the data you want to evaluate.
Define the filter conditions.
Save the filter.
Add the next step that should run when the filter condition passes.
Step-by-Step: Add a Loop
Add a Loop Step after a step that returns a list or collection.
Select the collection the loop should process.
Configure the loop behavior.
Add steps inside the loop for work that should happen for each item.
Add steps after the loop for work that should happen once the loop is complete.
App integrations may not be available inside every loop context. If an app cannot be added inside a loop, add it after the loop or use supported action and wait steps inside the loop.
Use Variables From Previous Steps
Variables let later steps use data from earlier steps. For example, an HTTP Request or app step can use a value from the trigger payload or from a previous formatter step.
Step-by-Step: Insert a Variable
Open the step that needs dynamic data.
Click into the field where the value should be inserted.
Open the variable picker when available.
Search or browse the available previous steps.
Select the field you want to insert.
Save or test the step.
If no variables are available, run or test earlier steps first so Whippy has sample data to show. You can also type placeholders manually when you know the step alias and field path.
Test a Workflow Before Publishing
Testing helps confirm that each step receives the expected input and returns usable output.
Use testing to check:
Trigger sample data
HTTP responses
Code output
Formatter output
App action responses
Condition or filter behavior
Loop configuration
Wait behavior
Step-by-Step: Test a Step
Open the step.
Complete any required setup and configuration fields.
Open Test.
Run the test.
Review input, output, response data, console output, or errors.
Adjust the step configuration if needed.
Save the step.
Publish and Fix Validation Issues
When you publish, Whippy checks the workflow for required configuration. If a step is incomplete, Whippy shows a validation message and highlights the affected step on the canvas.
Step-by-Step: Resolve Publish Validation Errors
Click Publish.
Read the validation message.
Find the highlighted step on the canvas.
Open the highlighted step.
Complete the missing setup, configuration, or test data.
Save the step.
Repeat for any other highlighted steps.
Click Publish again.
Tips and Best Practices
Build and test one section of the workflow at a time.
Use clear step names so run history is easier to read later.
Test earlier steps before relying on their variables in later steps.
Use formatter steps when later steps need cleaner or more predictable values.
Use filters when a workflow should stop unless criteria are met.
Use paths when different conditions should lead to different actions.
Add error handlers to supported steps when failures need a separate path.
Review workflow runs after publishing to confirm the live workflow behaves as expected.
Troubleshooting
Issue | Possible Cause | Fix |
I cannot add the step I expected | The selected location may not support that step type | Choose a different location or add the step outside the current loop, wait, or path context |
The app I need is not available inside a loop | App integrations may not be supported inside that loop body | Add the app after the loop or use supported Actions or Wait steps inside the loop |
Variables are not available | Earlier steps may not have sample data yet | Test or run earlier steps, then reopen the variable picker |
A test fails | Required fields, credentials, variables, or external API details may be incorrect | Review the test response, required fields, and connected account |
Publish fails | One or more steps are incomplete | Open the highlighted steps and complete the required configuration |
The workflow runs the wrong path | Conditions may be too broad, too narrow, or ordered incorrectly | Review each Conditional Paths step and test with realistic sample data |
A later step receives blank data | The variable may reference the wrong step or field | Reinsert the variable from the picker or confirm the step alias and output path |