Bubble implements branching logic through 'Only when' conditions on workflow actions and events, custom events for reusable branches, and conditional element visibility. You can create if/else patterns by adding multiple workflow events with mutually exclusive conditions, or use single workflows with conditional actions. Understanding how Bubble's execution model skips conditional actions without halting the workflow is key.
Implement Branching Logic in Bubble Workflows
This tutorial explains how to create conditional branching in Bubble workflows — the equivalent of if/else statements in code. You will learn three approaches: conditions on individual actions, multiple workflows with exclusive conditions, and custom events for complex branching. This is essential for any app with variable behavior based on user roles, data values, or form inputs.
Prerequisites
- A Bubble account with an existing app
- Basic understanding of workflows and events
- Familiarity with dynamic expressions and yes/no evaluations
Step-by-step guide
Add 'Only When' Conditions to Individual Actions
Add 'Only When' Conditions to Individual Actions
Open any workflow in the Workflow tab. Click on an action to open its settings. At the bottom, find 'Only when' and click to add a condition. Enter a dynamic expression that evaluates to yes or no — for example, 'Current User's role is admin'. When the condition is no, this action is skipped but subsequent actions still run. Important: if a later action references 'Result of step X' from the skipped action, that result will be empty.
Pro tip: When an action is skipped, its Result is empty/null. Always account for this in downstream actions that reference skipped steps.
Expected result: Individual workflow actions execute conditionally based on dynamic expressions.
Create If/Else Patterns with Multiple Workflows
Create If/Else Patterns with Multiple Workflows
For true if/else behavior, create separate workflows for each branch. For example, for a 'Submit' button: Workflow 1 — When Submit clicked, Only when Dropdown Role's value is 'Admin' → run admin-specific actions. Workflow 2 — When Submit clicked, Only when Dropdown Role's value is 'User' → run user-specific actions. Both workflows trigger on the same event but only one executes based on the condition. This is safer than using conditions on individual actions within a single workflow.
Expected result: Different workflows execute for different conditions, creating clean if/else branching.
Use Custom Events for Complex Branching
Use Custom Events for Complex Branching
For workflows with many branches, create Custom Events. Go to the Workflow tab, add a new custom event for each branch — for example, 'handle_admin_submission', 'handle_user_submission', 'handle_guest_submission'. Each custom event contains its specific actions. In your main workflow (button click), use 'Trigger a custom event' actions with appropriate 'Only when' conditions. The parent workflow pauses and waits for each triggered custom event to complete before continuing.
Expected result: Complex branching is organized into named custom events, making the logic readable and reusable.
Implement Nested Conditions
Implement Nested Conditions
For nested if/else logic (e.g., check role, then check status within each role), combine the approaches. The main workflow checks the top-level condition and triggers the appropriate custom event. Inside each custom event, add further 'Only when' conditions on actions. For deeply nested logic, chain custom events — one custom event triggers another based on its own conditions. Keep nesting to 2-3 levels maximum for maintainability.
Expected result: Multi-level conditional logic works through chained custom events and nested conditions.
Combine with Conditional Element Visibility
Combine with Conditional Element Visibility
Branching is not just for workflows — use conditional visibility on elements to show different UI based on conditions. On any element's Conditional tab, add: 'When Current User's role is admin → this element is visible'. This works independently of workflows and is the preferred approach for showing/hiding UI sections. Combine with workflow branching: show the right form elements, then run the right workflow when submitted.
Expected result: Both UI display and workflow execution branch based on conditions.
Complete working example
1BRANCHING PATTERNS IN BUBBLE23PATTERN 1: Conditional Actions (Simple)4 When Submit clicked5 → Create Order (always runs)6 → Send admin email (Only when: order total > $100)7 → Show success message (always runs)8 Note: If step 2 is skipped, step 3 still runs910PATTERN 2: Multiple Workflows (If/Else)11 When Submit clicked + Only when Current User's role is 'admin'12 → Create Order with admin privileges13 → Log admin action14 When Submit clicked + Only when Current User's role is 'user'15 → Create Order with standard flow16 → Send confirmation email17 When Submit clicked + Only when Current User is logged out18 → Show login prompt1920PATTERN 3: Custom Events (Complex)21 Custom Event: process_admin_order (params: order_data)22 → Create Order → Apply discount → Notify warehouse23 Custom Event: process_user_order (params: order_data)24 → Create Order → Charge payment → Send receipt25 When Submit clicked26 → Trigger process_admin_order (Only when role is admin)27 → Trigger process_user_order (Only when role is user)2829PATTERN 4: Nested Conditions30 When Submit clicked31 → Trigger handle_by_role32 Custom Event: handle_by_role33 → Trigger handle_admin (Only when role is admin)34 → Trigger handle_user (Only when role is user)35 Custom Event: handle_admin36 → Create Order as admin37 → Apply bulk discount (Only when items > 10)38 → Notify manager (Only when total > $500)Common mistakes when building branching logic in Bubble workflows
Why it's a problem: Assuming skipped actions halt the workflow
How to avoid: If you need true if/else where only one branch runs, use separate workflows with mutually exclusive conditions at the workflow level.
Why it's a problem: Referencing 'Result of step X' from a conditionally skipped step
How to avoid: Add a condition on the downstream action to only run when the referenced step actually executed, or use separate workflows.
Why it's a problem: Creating deeply nested branching that is hard to debug
How to avoid: Flatten complex branching by using separate workflows or custom events with descriptive names.
Best practices
- Use separate workflows with mutually exclusive conditions for clear if/else patterns.
- Name custom events descriptively (e.g., 'process_premium_order' not 'custom_event_1').
- Keep branching depth to 2-3 levels maximum for maintainability.
- Always account for the 'else' case — add a default branch that handles unexpected conditions.
- Use the Debugger's step-by-step mode to verify which branches execute.
- Document complex branching logic with Bubble's Notes feature.
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I need to implement if/else branching in Bubble.io workflows. I have a form where the behavior changes based on user role (admin, editor, viewer) and order total. What's the best pattern for conditional workflow execution in Bubble?
Implement branching logic for the order form. If the user is an admin, apply bulk pricing and skip payment. If the user is a regular user, charge payment and send receipt. If the order is over $100, notify the manager regardless of role.
Frequently asked questions
Does Bubble have a native if/else action?
No. Bubble uses 'Only when' conditions on actions and workflows instead of explicit if/else blocks. For true if/else behavior, use separate workflows with mutually exclusive conditions.
Can I use 'Only when' on an entire workflow?
Yes. Click on the workflow event (e.g., 'When Button is clicked') and add a condition. The entire workflow only fires when the condition is true. This is the cleanest way to create if/else branches.
How do I create a switch/case pattern?
Create separate workflows for each case, all triggered by the same event, each with a unique 'Only when' condition matching a different value. This emulates a switch statement.
Can I branch backend workflows?
Yes. Backend workflows support 'Only when' conditions on both the workflow trigger and individual actions. Custom events work differently in backend workflows — use scheduled API workflows for backend branching.
How do I debug which branch was taken?
Use the Step-by-step Debugger in Preview mode. It shows which actions ran and which were skipped, with the condition evaluation visible. For complex branching, RapidDev can help architect clean, testable workflow patterns.
What happens if no branch condition is met?
Nothing executes — no workflow fires. Always include a default/fallback branch to handle unexpected cases, such as showing an error message.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation