Home 🔁 Flows Building

🔁 Flows Building

Flows Building is Pickle’s workflow automation application. Learn how to create, manage and troubleshoot automated flows, including triggers, actions, permissions and common issues.
By ThinkPickle Admin
13 articles

🔁 Flows Building: Overview & Support Guide

Article content Flows Building is Pickle’s application for designing, managing and running automated workflows. This article explains: - What Flows Building is - What you can do with it - How support works - Where to go for help when something isn’t working If you’re new to Flows Building, start here. What Is Flows Building? Flows Building allows you to create automated workflows by connecting steps (nodes) together in a visual flow. Flows are used to: - Automate repeatable processes - Trigger actions based on events - Reduce manual work - Improve consistency across systems Once a flow is published, it runs automatically based on the conditions you define. What You Can Do in Flows Building With Flows Building, you can: - Create and edit workflows - Connect triggers, conditions and actions - Control how and when flows run - Test flows before publishing - Update or disable flows as requirements change Flows can be simple or complex, depending on your needs. Typical Use Cases Flows Building is commonly used for: - Process automation - System integrations - Event-driven actions - Data handling or routing - Reducing manual operational steps Each flow is tailored to your specific business logic. Getting Started If you’re new to Flows Building: 1. Review your use case and desired outcome 2. Create a new flow 3. Add and connect the required steps 4. Test the flow behaviour 5. Publish the flow Flows should always be tested before being used in production. Making Changes to Flows You can update flows at any time to: - Adjust logic - Add or remove steps - Fix issues - Improve performance Depending on your setup, changes may take effect immediately or after republishing. Common Issues Users Encounter Some common reasons a flow may not behave as expected include: - The flow is not published - A trigger condition is not met - A required step is misconfigured - Permissions or access are missing - External systems are unavailable Most issues can be identified by reviewing the flow configuration and recent changes. Getting Help With Flows Building If you need help with Flows Building, support works best when you can provide: - The name of the flow - What you expected to happen - What actually happened - When the issue occurred - Any recent changes made This helps support identify the issue more quickly. When to Contact Support Contact Pickle Support if: - A flow is not triggering - Actions are failing - You cannot publish or update a flow - You suspect a system or permission issue - You need help designing a flow Support can help troubleshoot issues and guide best practice. Where to Go Next Depending on what you need to do next, see: - Setting up your first flow - Editing and publishing flows - Troubleshooting Flows Building issues - Managing access and permissions These articles go into more detail on specific tasks. Final Notes Flows Building is designed to be flexible and powerful. Taking time to plan and test your flows will help ensure reliable outcomes and fewer issues over time.

Last updated on Feb 05, 2026

🚀 Setting Up Your First Flow

Article content This article walks you through creating your first flow in Flows Building, from initial setup through to publishing. Flows should always be tested before being published to ensure they behave as expected. Steps to Create a Flow To create your first flow: 1. Open Flows Building 2. Select Create New Flow 3. Give the flow a clear and descriptive name 4. Add a trigger node to define when the flow should start 5. Add the required action or condition nodes 6. Connect the nodes in the correct order to define the flow logic A flow will not run unless all required nodes are connected correctly. Testing Before Publishing Before publishing your flow, it’s important to test the configuration. Before publishing, confirm: - Trigger conditions are correct - All required fields are completed - Test events are run where available Testing helps prevent unexpected behaviour once the flow is live. Publishing the Flow Once your flow is ready: - Publish the flow to activate it - Events that meet the trigger conditions will begin running automatically You can: - Edit the flow at any time - Unpublish the flow if changes are needed - Republish once updates are complete Changes do not affect live behaviour until the flow is published. Best Practices - Start with simple flows and build complexity gradually - Make one change at a time - Test after every significant update - Use clear naming so flows are easy to identify later Related Articles - Editing and publishing flows - Troubleshooting Flows Building issues

Last updated on Feb 05, 2026

🧩 Understanding Flow Nodes: Triggers, Conditions, Actions & Variables

Article content Flows in Flows Building are created by connecting nodes together. Each node plays a specific role in controlling when a flow runs, how decisions are made, what actions occur, and how data is stored and reused. This article explains the four core node types: - Triggers - Conditions - Actions - Variables Understanding these concepts is essential for building reliable and predictable flows. What Is a Flow Node? A node is a single step in a flow. Nodes are connected in sequence to define the logic of your automation. The order and configuration of nodes determine how the flow behaves. Triggers A trigger defines when a flow starts. Every flow must have at least one trigger. If the trigger conditions are not met, the flow will not run. Key points about triggers - Triggers listen for specific events - They start the flow automatically - They only activate when defined criteria are met Triggers should be configured carefully to avoid flows running too often or not at all. Conditions Conditions allow a flow to make decisions. They check whether specific criteria are true or false and determine which path the flow should follow. Conditions are used to - Branch a flow into different paths - Stop a flow when criteria are not met - Control whether actions should run Conditions usually evaluate data provided by triggers or earlier actions. How Conditions Work - Conditions evaluate data at runtime - Each condition results in a true/false outcome - The flow follows the path that matches the result Placing conditions before dependent actions is critical to correct behaviour. Actions An action defines what the flow does. Actions are the steps that perform work once a flow is running. Common action purposes - Creating or updating records - Sending notifications or messages - Forwarding or routing events - Triggering external systems A flow can include multiple actions, which run in the order they are connected. Variables Variables are used to store and reuse data within a flow. They allow you to capture information once and reference it later, making flows more flexible and efficient. What Variables Are Used For Variables can be used to: - Store values from triggers or actions - Reuse data across multiple steps - Simplify complex logic - Reduce repeated configuration For example, a variable might store a caller’s number, an ID, or a calculated value. How Variables Work - Variables are created during flow execution - Their values can be updated as the flow runs - Other nodes can reference variables when needed If a variable is empty or missing, actions that rely on it may fail. How Nodes Work Together A typical flow follows this structure: 1. A trigger starts the flow 2. One or more conditions evaluate logic 3. Variables store or pass data between steps 4. Actions perform the required tasks Incorrect ordering or missing configuration can cause flows to stop or behave unexpectedly. Best Practices for Using Nodes To build reliable flows: - Keep logic simple where possible - Use conditions before actions that depend on data - Name variables clearly - Avoid unnecessary branching - Test each logic path before publishing Clear structure makes flows easier to maintain and troubleshoot. Common Node-Related Issues Some common problems include: - Triggers that are too broad or too narrow - Conditions placed after actions - Variables referenced before being set - Actions missing required input data Most issues can be resolved by reviewing node order and configuration. When to Review Node Logic Review triggers, conditions, actions and variables if: - A flow is not triggering - Actions fail unexpectedly - The flow runs too often or not often enough - Recent changes were made Small adjustments often resolve larger issues. Related Articles - Setting up your first flow - Editing, versioning & publishing flows - Common mistakes when building flows - Troubleshooting Flows That Are Not Triggering - Troubleshooting Actions That Fail -

Last updated on Feb 05, 2026

✏️ Editing, Versioning & Publishing Flows

Article content Flows in Flows Building can be updated at any time to reflect new requirements, fix issues, or improve behaviour. This article explains how editing works, how changes are applied, and what happens when you publish a flow. Editing an Existing Flow To edit a flow: 1. Open Flows Building 2. Select the flow you want to update 3. Make the required changes to triggers, conditions, or actions 4. Save your changes Saved changes are not live until the flow is published. Understanding Draft vs Published Flows Flows exist in two states: Draft - Contains your latest saved changes - Can be edited freely - Does not affect live behaviour Published - Is the active version of the flow - Responds to real events - Runs automatically when triggers occur Editing a flow creates a draft version until you publish again. Publishing a Flow Publishing applies your draft changes and makes them live. When you publish: - The current draft replaces the previously published version - The flow immediately begins running with the new logic - Any events that meet trigger conditions will be processed Publishing is required for changes to take effect. Versioning and Change Management Flows Building maintains logical separation between drafts and live flows, which helps prevent accidental changes. Best practices for managing changes - Make one change at a time - Save frequently while editing - Publish only after testing - Avoid major changes during peak usage periods Keeping changes small makes issues easier to identify and reverse. Testing After Publishing After publishing a flow: - Run test events where possible - Confirm expected actions occur - Monitor behaviour shortly after changes If issues appear, you can edit the flow again and republish a corrected version. Unpublishing a Flow You can unpublish a flow if needed. When a flow is unpublished: - It stops responding to triggers - No actions are executed - The configuration is retained for later use Unpublishing is useful during maintenance or investigation. Common Editing Mistakes Some common issues include: - Forgetting to publish after making changes - Publishing incomplete drafts - Making multiple changes at once - Not testing updated logic Taking time to review changes before publishing reduces risk. When to Update a Flow You may need to edit and republish a flow if: - Business requirements change - Logic needs refinement - An issue is identified - External systems change behaviour Regular reviews help keep flows reliable and relevant. Related Articles - Setting up your first flow - Understanding triggers, conditions & actions - Common mistakes when building flows - Troubleshooting Flows Building issues

Last updated on Feb 05, 2026

🔐 Managing Access & Permissions in Flows Building

Article content Access to Flows Building is controlled through user permissions. Managing access correctly helps protect your workflows, prevents accidental changes, and ensures only authorised users can publish live flows. Understanding Access in Flows Building Not every user needs the same level of access. Permissions determine what a user can: - View - Edit - Publish - Manage Access should be granted based on responsibility, not convenience. Common Permission Levels While permission names may vary, access typically falls into the following levels. View Only Users can: - View existing flows - Review configuration and logic Users cannot make changes or publish flows. Edit Access Users can: - Create new flows - Edit existing flows - Save draft changes Users cannot publish changes unless granted publishing rights. Publish Access Users can: - Publish flows - Make changes live - Unpublish active flows This level should be restricted to trusted users. Administrative Access Administrators can: - Manage user access - Assign or remove permissions - Oversee all flows Administrative access should be limited to a small number of users. Best Practices for Managing Permissions To keep Flows Building secure and stable: - Grant the lowest level of access required - Limit publishing access to experienced users - Review access regularly - Remove access when staff change roles or leave - Avoid shared accounts Clear ownership reduces errors and accountability issues. Why Publishing Access Matters Publishing directly affects live behaviour. Incorrect publishing can: - Trigger actions unexpectedly - Interrupt automated processes - Cause downstream system issues Restricting publish access reduces risk. Reviewing and Updating Access You should review permissions when: - New team members join - Roles or responsibilities change - Issues occur due to unexpected changes - Regular security reviews are performed Access reviews help maintain long-term stability. Troubleshooting Permission Issues If a user cannot perform an action: - Confirm their assigned permission level - Check whether publishing rights are required - Verify they are accessing the correct environment If access still doesn’t behave as expected, support can help investigate. When to Contact Support Contact Pickle Support if: - A user cannot access Flows Building - Permissions appear incorrect - Publishing access is blocked unexpectedly - You need help assigning the correct access level Providing the affected user name and flow details helps resolve issues faster. Related Articles - Setting up your first flow - Editing, versioning & publishing flows - Common mistakes when building flows - Troubleshooting Flows Building issues

Last updated on Feb 05, 2026

⚠️ Common Mistakes When Building Flows

Article content Most issues in Flows Building are caused by small configuration mistakes rather than system faults. This article highlights common mistakes users make when building flows and explains how to avoid them. Flow Not Published One of the most common issues is forgetting to publish a flow. What happens - The flow exists only as a draft - No triggers or actions will run How to avoid it - Always publish after making changes - Confirm the flow status shows as published Triggers Too Broad or Too Narrow Triggers that are not configured carefully can cause flows to behave unexpectedly. Too broad - The flow runs more often than intended - Actions trigger unnecessarily Too narrow - The flow rarely or never runs How to avoid it - Review trigger conditions carefully - Test with real or sample events Conditions in the Wrong Order Conditions must be placed before actions that depend on them. Common issue - Actions execute before required conditions are checked How to avoid it - Validate logic step-by-step - Ensure conditions come before dependent actions Missing Required Fields Some actions require mandatory fields to run successfully. What happens - The flow triggers but actions fail - Data is incomplete or rejected How to avoid it - Check all required fields - Validate input data before actions run Making Too Many Changes at Once Large or multiple changes make it difficult to identify the cause of issues. How to avoid it - Make one change at a time - Test after each update - Publish incrementally Not Testing Before Publishing Publishing without testing can cause unexpected behaviour in live environments. How to avoid it - Use test events where available - Validate logic paths manually - Review recent changes before publishing Assuming External Systems Will Always Respond Flows often rely on external systems. What happens - Actions fail when external services are unavailable - Errors propagate through the flow How to avoid it - Plan for failures - Validate inputs and outputs - Monitor behaviour after publishing Ignoring Permissions and Access Limits Users without proper access may not be able to edit or publish flows. How to avoid it - Confirm user permissions - Limit publishing access to authorised users When to Review a Flow for Mistakes You should review a flow if: - It behaves differently than expected - Actions fail intermittently - It runs too often or not often enough - Changes were made recently Most issues can be resolved by reviewing logic and configuration. Next Steps If reviewing common mistakes does not resolve the issue: - Recheck triggers, conditions and actions - Confirm the flow is published - Review permissions If problems persist, see Troubleshooting Flows Building issues. Related Articles - Understanding triggers, conditions & actions - Editing, versioning & publishing flows - Managing access & permissions in Flows Building - Troubleshooting Flows Building issues

Last updated on Feb 05, 2026

🛠️ Troubleshooting Flows That Are Not Triggering

Article content If a flow in Flows Building is not triggering, it usually means a configuration or logic condition is preventing it from starting. This article helps you identify the most common reasons a flow does not trigger and what to check before contacting support. Start With the Basics Before diving deeper, confirm the following: - The flow is published - The triggering event has actually occurred - The flow is enabled and not paused or unpublished If any of these are not true, the flow will not run. Check the Trigger Configuration Triggers define when a flow starts. If the trigger conditions are not met, the flow will not trigger. Check that: - The correct trigger type is selected - Trigger conditions match the event you expect - Required trigger fields are populated - Values are not too restrictive or too broad Even a small mismatch can prevent the trigger from firing. Confirm the Triggering Event Occurred Flows only trigger when the defined event happens. Ask yourself: - Did the event actually occur? - Did it occur after the flow was published? - Is the event type supported by the trigger? Events that occurred before publishing will not trigger the flow. Review Conditions Immediately After the Trigger Conditions placed immediately after a trigger can stop a flow early. Check whether: - Conditions evaluate to false - Data used in conditions is present and valid - Logic paths are set correctly If a condition fails, the flow may stop without running any actions. Look for Missing or Invalid Data Some triggers rely on data being available at runtime. Common issues include: - Empty fields - Unexpected data formats - Assumptions about values always being present If required data is missing, the flow may not proceed past the trigger. Check Recent Changes If the flow previously worked and now does not: - Review recent edits to triggers or conditions - Confirm the flow was republished after changes - Check whether permissions or access were modified Recent changes are often the cause of new issues. Verify Permissions and Access Insufficient permissions can affect flow behaviour. Confirm that: - The user who published the flow has the correct access - Required system permissions are still in place - No access restrictions were introduced Permission-related issues can prevent flows from running as expected. Test With a Simple Scenario To isolate the issue: - Temporarily simplify the trigger - Remove conditions - Test with a known event If the simplified flow triggers, reintroduce logic step by step to find the cause. When to Contact Support Contact Pickle Support if: - The flow is published and still not triggering - Trigger conditions appear correct - Events are occurring as expected - You cannot identify why the flow is not running When contacting support, include: - The flow name - The trigger type used - What you expected to happen - What actually happened - Approximate time of the triggering event This information helps speed up investigation. Related Articles - Understanding triggers, conditions & actions - Editing, versioning & publishing flows - Common mistakes when building flows - Managing access & permissions in Flows Building

Last updated on Feb 05, 2026

❌ Troubleshooting Actions That Fail

Article content If a flow in Flows Building triggers successfully but one or more actions fail, the issue is usually related to configuration, data, permissions, or external systems. This article explains the most common reasons actions fail and how to identify and resolve them. Confirm the Flow Triggered Before troubleshooting actions, confirm that: - The flow did trigger - The failure occurred after the trigger - The correct flow version is published If the flow did not trigger at all, see Troubleshooting Flows That Are Not Triggering. Check Action Configuration Actions require specific configuration to run successfully. Check that: - All required fields are completed - Field values are mapped correctly - Data types and formats match expectations Missing or incorrect configuration is one of the most common causes of action failures. Validate Input Data Actions often rely on data passed from earlier steps. Common data issues include: - Empty or null values - Unexpected formats (for example text instead of numbers) - Fields that only exist in certain scenarios Ensure that data is present and valid before the action runs. Adding conditions earlier in the flow can help protect actions from invalid input. Review Action Order Actions run in the order they are connected. Check whether: - An action depends on output from a previous step - Required data is generated before the action runs - Actions are placed after any necessary conditions Incorrect ordering can cause actions to fail even when configuration appears correct. Check Permissions and Credentials Some actions require specific permissions or credentials. Failures may occur if: - Credentials have expired or been revoked - Access permissions have changed - The action is attempting to perform an unauthorised operation Confirm that any required credentials are current and have the necessary access. Consider External System Availability Many actions interact with external systems. Action failures can occur if: - The external system is unavailable - Rate limits are exceeded - The external service returns an error Temporary failures may resolve once the external system recovers. Review Recent Changes If actions previously worked and now fail: - Review recent edits to the flow - Check for changes to credentials or permissions - Confirm the flow was republished after updates Recent changes are often the root cause. Test Actions in Isolation To isolate the problem: - Temporarily simplify the flow - Trigger the action with known good data - Remove unrelated actions This approach helps identify whether the issue is with the action itself or earlier logic. When to Contact Support Contact Pickle Support if: - Actions continue to fail despite correct configuration - Failures occur intermittently without a clear cause - You need help interpreting errors or behaviour When contacting support, include: - The flow name - The action that failed - What you expected the action to do - What actually happened - Approximate time of the failure Providing this information helps speed up resolution. Related Articles - Troubleshooting Flows That Are Not Triggering - Understanding triggers, conditions & actions - Editing, versioning & publishing flows - Common mistakes when building flows

Last updated on Feb 05, 2026

🆘 How to Get Support for Flows Building

Article content This article explains how support works for Flows Building, including what to check before contacting support, what information to provide, and how issues are escalated. Following these steps helps issues be resolved faster. Before Contacting Support Many Flows Building issues can be resolved by checking configuration first. Before contacting support, confirm: - The flow is published - Triggers are configured correctly - Conditions evaluate as expected - Actions are correctly configured - Recent changes were tested You may find answers in: - Troubleshooting Flows That Are Not Triggering - Troubleshooting Actions That Fail - Common mistakes when building flows What Support Can Help With Pickle Support can assist with: - Flows not triggering or behaving unexpectedly - Actions failing or producing incorrect results - Permissions and access issues - Publishing or configuration problems - Guidance on best practice flow design Support can also help identify whether an issue is configuration-related or system-related. What Support Cannot Do To set expectations, support generally cannot: - Design complex flows on your behalf - Modify production flows without approval - Troubleshoot third-party systems outside Pickle’s control - Recover data from failed external systems Support focuses on ensuring Flows Building operates correctly and reliably. Information to Include in a Support Request Providing complete information helps support investigate quickly. Include: - The flow name - What you expected to happen - What actually happened - Approximate date and time of the issue - Whether the issue is ongoing or intermittent - Any recent changes made Incomplete requests may require follow-up before investigation can begin. Reporting Urgent Issues If a flow failure is causing significant impact: - Clearly mark the request as urgent - Describe the business impact - Include the time the issue started Urgent issues are prioritised based on impact and severity. Support Escalation Process Issues may be escalated if: - The problem cannot be resolved at first review - A system-level fault is suspected - The issue affects multiple flows or users During escalation: - Additional diagnostics may be performed - You may be asked for more information - Updates will be provided as the issue progresses Escalation ensures complex issues receive the appropriate level of attention. After the Issue Is Resolved Once resolved: - Review the flow configuration - Apply any recommended changes - Monitor behaviour to confirm stability Learning from resolved issues helps prevent future problems. Related Articles - Flows Building: Overview & Support Guide - Troubleshooting Flows That Are Not Triggering - Troubleshooting Actions That Fail - Common mistakes when building flows - Managing access & permissions in Flows Building Final Notes Providing clear information and following troubleshooting steps helps support resolve issues faster and reduces repeat problems. Flows Building is a powerful tool — good support outcomes start with good preparation.

Last updated on Feb 05, 2026

📜 Using Flow Logs for Troubleshooting

Article content Flow Logs in Flows Building provide a record of how flows run, including when they trigger, what actions execute, and where failures occur. Using Flow Logs is one of the most effective ways to troubleshoot unexpected flow behaviour. What Are Flow Logs? Flow Logs record information about each flow run, such as: - When a flow was triggered - Which steps were executed - Data passed between steps - Errors or failures encountered Logs help you understand what happened, not just what you expected to happen. When to Use Flow Logs You should review Flow Logs if: - A flow is not triggering - An action fails - A flow behaves differently than expected - Issues occur intermittently - You need evidence for troubleshooting or support Flow Logs are especially useful after recent changes. Accessing Flow Logs To view Flow Logs: 1. Open Flows Building 2. Select the relevant flow 3. Open the Logs or Execution History section 4. Choose a specific run or time period Log availability may vary depending on your configuration. Understanding Log Entries Each log entry typically shows: - Trigger details - Step-by-step execution order - Inputs and outputs for each step - Error messages, if any Reading logs from top to bottom shows how the flow progressed. Identifying Common Issues in Logs Flow Did Not Trigger - No log entry exists - Indicates the trigger never fired Check trigger conditions and event timing. Flow Triggered but Stopped Early - Log shows trigger but no subsequent actions - Often caused by failed conditions Review condition logic and data values. Action Failed - Log entry includes an error or failure state - Often linked to configuration, data or permissions Check action setup and required fields. Using Logs to Isolate Problems To isolate issues: - Compare successful and failed runs - Look for differences in input data - Identify the exact step where execution stops Logs help pinpoint where logic or configuration breaks down. Best Practices for Using Flow Logs - Review logs after publishing changes - Save examples of failures for reference - Use logs before contacting support - Combine logs with configuration review Logs are most effective when used early in troubleshooting. What Flow Logs Don’t Show Flow Logs may not include: - Detailed third-party system errors - External system internal logs - Network-level issues Some failures may require checking external systems separately. When to Contact Support Contact Pickle Support after reviewing Flow Logs if: - Errors are unclear or unexplained - Logs indicate a system-level issue - Behaviour differs from configuration When contacting support, include: - Flow name - Log timestamps - Relevant log excerpts - Description of expected vs actual behaviour This helps speed up investigation. Related Articles - Troubleshooting Flows That Are Not Triggering - Troubleshooting Actions That Fail - Understanding triggers, conditions & actions - How to Get Support for Flows Building

Last updated on Feb 05, 2026

🧪 Flow Examples & Common Patterns

Article content Flows Building supports a wide range of automation scenarios. This article outlines common flow patterns and examples to help you design effective and reliable flows. These examples focus on structure and logic, not specific configurations. Example 1 — Simple Trigger → Action Flow Use case Automatically perform an action when an event occurs. Pattern 1. Trigger 2. Action When to use - Straightforward automation - No decision-making required Notes - Keep triggers specific - Ensure required action fields are populated Example 2 — Trigger → Condition → Action Use case Only perform an action when certain criteria are met. Pattern 1. Trigger 2. Condition 3. Action When to use - Filtering events - Preventing unnecessary actions Notes - Place conditions immediately after triggers - Test both true and false paths Example 3 — Trigger → Multiple Conditions → Different Actions Use case Handle different scenarios in different ways. Pattern 1. Trigger 2. Condition A → Action A 3. Condition B → Action B When to use - Routing logic - Business rule handling Notes - Ensure conditions are mutually exclusive where required - Avoid overlapping logic Example 4 — Using Variables to Reuse Data Use case Store information once and reuse it later in the flow. Pattern 1. Trigger 2. Set variable 3. Condition or Action using variable When to use - Reusing IDs or values - Simplifying complex flows Notes - Always ensure variables are set before use - Use clear variable names Example 5 — Guarded Actions (Safe Execution) Use case Prevent actions from running with invalid data. Pattern 1. Trigger 2. Condition (validate data) 3. Action When to use - External system interactions - Data-sensitive actions Notes - Guard conditions reduce failures - Combine with logging where possible Example 6 — Temporary or Controlled Flow Execution Use case Enable or disable automation without deleting the flow. Pattern - Publish / unpublish flow as needed When to use - Maintenance - Testing - Temporary business changes Common Patterns to Avoid Avoid these patterns where possible: - Overly complex branching - Deep condition nesting - Using actions before validating data - Referencing variables that may not exist Simpler flows are easier to maintain and troubleshoot. How to Use These Patterns When designing a new flow: 1. Identify the trigger 2. Decide if conditions are required 3. Determine what data must be stored 4. Add actions in the correct order 5. Test each path before publishing Patterns help you build consistently and reduce errors. Related Articles - Understanding Flow Nodes: Triggers, Conditions, Actions & Variables - Setting up your first flow - Editing, versioning & publishing flows - Common mistakes when building flows - Troubleshooting Flows That Are Not Triggering

Last updated on Feb 05, 2026

🧠 Flow Node Functions Explained

Article content Flows in Flows Building are built by connecting nodes together. Each node has a specific function and controls how calls and events are handled. This article explains every node type available in Flows Building, exactly as they appear in the flow editor. Trigger Nodes Incoming Call What it does Starts the flow when an inbound call is received. When to use it - Call routing - IVR menus - Time-based or geographic call handling Important notes - The flow will only trigger for calls received after the flow is published - Each flow must have at least one trigger Condition Nodes Condition nodes evaluate logic and decide which path the flow should follow. Contact Data Is What it does Checks whether specific contact data exists or matches a value. Common uses - Known vs unknown callers - Tagged or categorised contacts Things to watch - Contact data may not always exist - Always handle false outcomes Time Is What it does Checks the current time against defined hours. Common uses - Business hours vs after-hours routing - Lunch breaks or shift changes Things to watch - Time is evaluated at the moment the flow runs Date-Time Is What it does Checks a specific date and time. Common uses - Public holidays - One-off events - Temporary routing changes Things to watch - Date-time rules override normal time logic Day Is What it does Checks the day of the week. Common uses - Weekday vs weekend handling - Different routing by day Caller’s Number Is What it does Matches the caller’s phone number. Common uses - Blocking specific numbers - VIP routing - Known caller handling Things to watch - Number formats must match correctly Caller’s Postcode Is What it does Checks the caller’s postcode based on their number. Common uses - Local call routing - Regional service handling Things to watch - Postcode detection depends on number data availability Caller’s State Is What it does Checks the caller’s state. Common uses - State-based routing - Public holiday handling by state AB Split What it does Randomly splits calls into two or more paths. Common uses - Load sharing - Testing different call flows - Comparing outcomes Things to watch - Use only when random distribution is acceptable Action Nodes Action nodes define what happens once a flow is running. Forward Call What it does Forwards the call to another number or destination. Common uses - Route calls to staff or teams - Overflow handling Pause What it does Adds a short delay before the next action. Common uses - Natural spacing between announcements - Timing control Say / Play What it does Plays a recorded message or text-to-speech audio. Common uses - Greetings - Announcements - IVR prompts Record Voicemail What it does Records a voicemail from the caller. Common uses - After-hours handling - Missed calls Gather Input What it does Collects keypad input from the caller. Common uses - IVR menus - Option selection Things to watch - Always handle invalid or no input Reject Call What it does Ends the call without forwarding. Common uses - Blocking unwanted calls - Out-of-scope routing Send Analytics Event What it does Sends an analytics event for tracking and reporting. Common uses - Measuring call flow performance - Tracking IVR selections Send Email What it does Sends an email notification. Common uses - Alerting staff - Voicemail notifications Send SMS Message What it does Sends an SMS message. Common uses - Caller follow-ups - Notifications or confirmations How Nodes Work Together A typical flow works like this: 1. Incoming Call trigger starts the flow 2. Condition nodes decide how the call should be handled 3. Action nodes perform routing, messaging or recording Correct order and configuration are essential for predictable behaviour. Common Node Mistakes - Forgetting to publish the flow - Placing conditions after actions - Not handling false condition paths - Missing required fields in actions Review node order carefully when troubleshooting. Related Articles - Understanding Flow Nodes: Triggers, Conditions, Actions & Variables - Flow Examples & Common Patterns - Common mistakes when building flows - Troubleshooting Flows That Are Not Triggering - Using Flow Logs for Troubleshooting

Last updated on Feb 05, 2026