# How to set conditional logic for step execution in Bubble workflows: Step-by-Ste

- Tool: Bubble
- Difficulty: Intermediate
- Time required: 15-20 min
- Compatibility: All Bubble plans
- Last updated: March 2026

## TL;DR

Control which workflow actions run by adding Only When conditions to individual steps in Bubble. This tutorial shows how to skip or execute specific actions based on custom states, user roles, or data values, reducing the need for multiple redundant workflows and keeping your logic clean and maintainable.

## Overview: Conditional Logic in Bubble Workflow Steps

This tutorial covers adding Only When conditions to individual steps within a Bubble workflow. Instead of creating separate workflows for every possible branch, you can conditionally skip or execute actions within a single workflow. You will learn how conditions interact with Result of step X references, how to use custom states as condition inputs, and when it is safer to split logic into separate workflows versus using step-level conditions.

## Before you start

- A Bubble account with an existing app
- At least one workflow already created in your app
- Basic understanding of Bubble data types and expressions
- Familiarity with the Workflow tab and action inspector

## Step-by-step guide

### 1. Open a workflow and select an action to condition

Go to the Workflow tab and click on an existing workflow event (for example, When Button Submit is clicked). Click on the action you want to conditionally execute. In the action's property panel, you will see a field labeled Only when at the bottom. Click it to open the expression editor. This is where you define the condition that must be true for this action to run.

**Expected result:** The Only when field is visible in the action inspector and ready for an expression.

### 2. Add a basic Only When condition

In the Only when field, build an expression that returns yes or no. For example: Current User's role is Admin. This means the action will only execute if the logged-in user has the Admin role. You can use any dynamic expression — database fields, custom states, URL parameters, or input values. If the condition evaluates to no, Bubble skips this action entirely and moves to the next one in the sequence.

> Pro tip: You can combine multiple conditions with and/or operators. For example: Current User's role is Admin and Input Form's value is not empty.

**Expected result:** The action now shows the Only when condition, and it will be skipped when the condition is false.

### 3. Use custom states as condition inputs

Custom states are ideal for controlling workflow step execution because they can be set earlier in the same workflow or on a previous user interaction. For example, set a custom state called should_send_email (yes/no) on the page based on a checkbox input. Then in your workflow, add Only when: Page's should_send_email is yes to the Send email action. This lets user choices dynamically control which steps run without creating separate workflows.

**Expected result:** The workflow action only fires when the custom state is set to yes, giving users control over optional steps.

### 4. Handle skipped steps that produce data

A critical nuance: if a skipped action produces data (like Create a new Thing), any later step referencing Result of step X will receive an empty value. This can cause unexpected behavior or errors. To handle this safely, either ensure dependent steps also have an Only when condition that matches, or restructure so data-producing steps are never conditionally skipped when later steps depend on their output. If you need branching with data dependencies, consider using separate workflows or custom events instead.

> Pro tip: If you need a workflow to always create a record but conditionally modify it, put the Create action without a condition and add Only when to the Make changes action.

**Expected result:** Your workflow handles skipped data-producing steps gracefully without empty reference errors.

### 5. Replace multiple workflows with conditional steps

Instead of creating three separate Button Click workflows for different user roles, create one workflow with conditional steps. For example: Action 1 (no condition) — Create a new Order. Action 2 (Only when Current User's role is Admin) — Make changes to Order, set status = approved. Action 3 (Only when Current User's role is not Admin) — Make changes to Order, set status = pending. This consolidates logic and makes it easier to maintain.

> Pro tip: For very complex branching (more than 3 paths), it is often cleaner to use custom events instead — each custom event handles one path and is triggered conditionally from the main workflow.

**Expected result:** A single workflow handles multiple user roles by conditionally executing different actions.

### 6. Test conditional steps with the Debugger

Open your app in Preview mode and activate the Debugger by clicking the bug icon. Trigger the workflow and step through each action. The Debugger shows whether each action was executed or skipped based on its Only when condition. Check that skipped actions show as skipped (not errored) and that the workflow continues past them correctly. Test with different user roles, input states, and custom state values to verify all paths.

**Expected result:** The Debugger confirms that conditional actions are correctly executed or skipped based on the Only when expression.

## Complete code example

File: `Workflow summary`

```text
CONDITIONAL STEP EXECUTION — WORKFLOW SUMMARY
================================================

SCENARIO: Order submission with role-based processing

PAGE CUSTOM STATES:
  Page
    - should_notify (yes/no) — set by checkbox
    - order_priority (text) — set by dropdown

WORKFLOW: When Button Submit Order is clicked

  Action 1: Create a new Order
    (No condition — always runs)
    customer = Current User
    items = RepeatingGroup Cart's List of Products
    total = CartTotal's value
    status = pending

  Action 2: Make changes to Result of Step 1
    Only when: Current User's role is Admin
    status = approved
    approved_by = Current User
    approved_date = Current date/time

  Action 3: Make changes to Result of Step 1
    Only when: Current User's role is not Admin
    status = pending_review

  Action 4: Send email
    Only when: Page's should_notify is yes
    To: Result of Step 1's customer's email
    Subject: Order Confirmation
    Body: Your order has been placed.

  Action 5: Make changes to Result of Step 1
    Only when: Page's order_priority is Rush
    priority = high
    rush_fee = Result of Step 1's total * 0.15

  Action 6: Navigate to page order-confirmation
    (No condition — always runs)
    Send: Result of Step 1

KEY RULES:
  - Skipped actions return empty for Result of step X
  - Conditions on styles cannot be overridden
  - Multiple conditions use AND logic by default
  - Use custom events for complex branching (3+ paths)
  - Always test with Debugger to verify skip behavior
```

## Common mistakes

- **Referencing Result of step X from a conditionally skipped step** — If the step was skipped, its result is empty, causing downstream actions to fail or save blank data Fix: Add matching Only when conditions to dependent steps, or restructure so data-producing steps always run.
- **Using step conditions when workflow-level conditions would be simpler** — Adding Only when to every action in a workflow creates maintenance overhead and is error-prone when conditions change Fix: If all actions in a workflow share the same condition, put the condition on the workflow event itself rather than on each action.
- **Forgetting that skipped steps still allow subsequent steps to run** — Unlike workflow-level conditions that stop the entire workflow, an action-level Only when just skips that one action and continues to the next Fix: If you need to stop the workflow entirely, use the Terminate this workflow action or put the condition at the workflow level.
- **Overcomplicating a single workflow instead of using custom events** — More than three conditional branches in one workflow becomes difficult to read and debug Fix: Split complex branching into separate custom events and trigger them conditionally from the main workflow.

## Best practices

- Use Only when on individual actions for simple two-path branching within a workflow
- Put conditions at the workflow level when all actions share the same execution criteria
- Use custom states to pass user choices into workflow conditions without additional database reads
- Never reference Result of step X from a step that might be skipped — guard dependent steps with matching conditions
- Use the Debugger to step through conditional workflows and verify which actions execute
- Document complex conditional logic with Notes attached to the workflow event in the editor
- For more than three conditional branches, use custom events instead of step-level conditions
- Test all condition paths including edge cases like empty inputs or logged-out users

## Frequently asked questions

### What happens to subsequent steps when an action is skipped?

They continue to run normally. Only the specific action with the unmet Only when condition is skipped. The workflow does not stop.

### Can I use Or logic in an Only When condition?

Yes. Use the or operator in the expression editor to combine multiple conditions. For example: Current User's role is Admin or Current User's role is Manager.

### Is there a performance cost to adding many Only When conditions?

The conditions themselves are lightweight. However, if each condition includes a Do a search for expression, those searches consume workload units even when the action is ultimately skipped.

### Can I conditionally skip a step in a backend workflow?

Yes. Backend workflow actions support Only when conditions the same way as frontend workflows. The behavior is identical.

### How do I debug which steps were skipped?

Use the Debugger in Preview mode. Step through the workflow and it will show each action's status — whether it executed or was skipped due to its condition.

### Can RapidDev help optimize complex workflow logic?

Yes. RapidDev specializes in Bubble development and can help refactor complex conditional workflows into maintainable, efficient structures using custom events and backend workflows.

### Should I use conditions on steps or separate workflows?

For simple two-way branching, step conditions are cleaner. For three or more paths with different data dependencies, separate workflows or custom events are safer and easier to maintain.

---

Source: https://www.rapidevelopers.com/bubble-tutorial/set-conditional-logic-step-execution-bubble-workflows
© RapidDev — https://www.rapidevelopers.com/bubble-tutorial/set-conditional-logic-step-execution-bubble-workflows