Switch Case¶

Route workflow execution to one of several branches by matching an input value against a set of case values, similar to a switch-case statement in programming, enabling multi-way branching, value-based routing, and decision trees without chaining multiple Continue If blocks.

How This Block Works¶

This block compares a single input value against the keys of a case mapping and directs execution to the step associated with the first matching case. The block:

1. Takes a value input (typically a selector referencing a workflow input or a step output, e.g. a classification result) and converts it to a string
2. Looks the string up in the cases mapping, where each key is a case value and each value is the step to execute when that case matches (e.g. {"red": "$steps.on_red", "blue": "$steps.on_blue"})
3. If case_insensitive is enabled, the comparison ignores letter case
4. If a case matches, execution continues to that case's step and all other branches terminate
5. If no case matches, execution continues to the steps listed in default_next_steps
6. If no case matches and default_next_steps is empty, the branch terminates

Because the input value is converted to a string before matching, non-string values match their string representation: True matches the key "True", 1.0 matches "1.0" (not "1"), and a missing/None value matches "None". Each target step may appear at most once across cases and default_next_steps — to route several case values to the same logic, point each case at its own step or normalize the value upstream (e.g. with an Expression block).

Common Use Cases¶

• Routing by classification result: Send images down different processing paths based on the top class predicted by a classification model (e.g. "damaged" → alert branch, "ok" → logging branch, anything else → default review branch)
• Mode-based pipelines: Use a workflow input parameter (e.g. $inputs.mode) to select between alternative processing branches at runtime without editing the workflow
• Multi-way alerting: Route to different notification blocks (email, Slack, webhook) depending on a severity or category value computed earlier in the workflow
• Replacing chained conditions: Collapse a ladder of Continue If blocks comparing the same value against different constants into a single, easier-to-read block

Connecting to Other Blocks¶

This block controls workflow execution flow and can be connected:

• After classification or detection blocks to branch on predicted classes, counts, or other prediction properties (often via a Property Definition or Expression block that extracts the value to switch on)
• After workflow inputs to select a branch from a runtime parameter
• Before any downstream blocks (models, notifications, sinks) that should only run for a specific case — each case target becomes the head of its own execution branch
• With a default branch wired via default_next_steps to handle unmatched values, or left empty to simply stop when nothing matches

Type identifier¶

Use the following identifier in step "type" field: roboflow_core/switch_case@v1to add the block as as step in your workflow.

Properties¶

The Refs column marks possibility to parametrise the property with dynamic values available in workflow runtime. See Bindings for more info.

Available Connections¶

Input and Output Bindings¶

The available connections depend on its binding kinds. Check what binding kinds Switch Case in version v1 has.

{
    "name": "<your_step_name_here>",
    "type": "roboflow_core/switch_case@v1",
    "value": "$steps.classifier.top",
    "cases": {
        "blue": "$steps.on_blue",
        "red": "$steps.on_red"
    },
    "case_insensitive": false,
    "default_next_steps": [
        "$steps.fallback"
    ]
}