# \[Blocks explained\] - Switch and Selector

**URL:** <https://community.cumulocity.com/t/blocks-explained-switch-and-selector/14460>\
**Category:** Knowledge Base\
**Tags:** analytics, Streaming-Analytics-Apama, analytics-builder, blocks-explained\
**Created:** [May 26, 2026, 2:19pm UTC](https://community.cumulocity.com/t/blocks-explained-switch-and-selector/14460 "2026-05-26T14:19:36Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mario\_Heidenreich2](https://dub1.discourse-cdn.com/flex005/user_avatar/community.cumulocity.com/mario_heidenreich2/32/30462_2.png) [@Mario\_Heidenreich2](https://community.cumulocity.com/u/Mario_Heidenreich2)\
**Post date:** [May 26, 2026, 2:19pm UTC](https://community.cumulocity.com/t/blocks-explained-switch-and-selector/14460/1 "2026-05-26T14:19:36Z")

</div>

## Blocks Explained Series

Analytics Builder comes with dozens of built-in blocks for every kind of task. There are input and output blocks, but more importantly there is a whole zoo of blocks that are meant to build business logic:

- calculations and aggregations,
- logic combinations,
- and blocks that help you define and manipulate the general data flow.

This series tries to guide you through the jungle of blocks by providing helpful descriptions and examples on some of the most commonly used blocks and their typical use cases.

In this article, we are going to have a look at two blocks that are rarely used but are really helpful to describe conditional logic: the **Selector** and **Switch** blocks from the **Flow Manipulation** section.

## Overview

Both the **Selector** and the **Switch** block let you define some kind of if-then logic and bring more dynamic behaviour to your models. They do this very differently, though.

 ![Selector and Switch](https://europe1.discourse-cdn.com/flex005/uploads/cumulocity/original/3X/6/b/6b53fa3c26ae10d87e0a0baded77e6f0f6821a91.png)

The **Selector** works like a lookup. The output of the block is _always one_ of the values that you set as _parameter_. Which parameter is used as output is decided by the input ports. The first input port to receive a `boolean` true value will cause the correlated parameter to be sent (e.g. Input port 1 = true → _Input1_ is used).

If no input port is set to “true”, the value specified by _No Input_ is used.

**Switch** somewhat works the other way: it will send the value given _on the input port_ when the name given in _Selected Input_ matches that of the related parameter. Note that selecting here essentially only works during _deployment_ of an instance - because that is when parameters are determined and set - and won’t change during runtime. We’ll have a look at how this is still useful.

## Common Use Cases

### Generic lookup with **Selector**

The logic here is essentially “if this applies, send that as output”.

For example, this model takes the status.maintenance information and a temperature value to send an Event with the current working state of a device:

 ![Selector Example](https://europe1.discourse-cdn.com/flex005/uploads/cumulocity/original/3X/f/3/f32e5eeb30c92679a70f7f1ab0186980992b213c.png)

We assume that “Stopped” is the default state:

 ![Selector Param](https://europe1.discourse-cdn.com/flex005/uploads/cumulocity/original/3X/7/f/7f6a787edf3cd82483c47b11ee2fe75795f31f52.png)  
If a measurement with a value \> 50 °C is received during a maintenance window, the status would still be “Maintenance”. Both input ports would be “true”, but since the maintenance check is on a lower port, it takes precedence.

### Switch behaviour per model instance depending on device or context

**Switch** takes _one_ of its inputs and uses that as output.

In this model we take either a value read from a device (`Managed Object`) or from a constant value to calculate a derived measurement:

 ![Switch Example](https://europe1.discourse-cdn.com/flex005/uploads/cumulocity/original/3X/1/f/1fdab4f02dc9c47d0e1ae471364d561eb62abc51.png)

We define a template parameter called “offsetSource” to represent this choice:

 ![Template Params](https://europe1.discourse-cdn.com/flex005/uploads/cumulocity/original/3X/a/8/a87bec4bf1ef0068692a08e6b0c50895757b9419.png)

It’s best to set this as a fixed list of values, since they need to match the names of the input parameters later:

 ![Offset Source Param](https://europe1.discourse-cdn.com/flex005/uploads/cumulocity/original/3X/9/2/92f7c220ab6b3e5efd4a4f8d86131476b30f470c.png)

With this, the configuration would use the template parameter like this:

 ![Switch Params](https://europe1.discourse-cdn.com/flex005/uploads/cumulocity/original/3X/2/d/2dc1de5d826ea460d77dce7fcd26bd7da02f05e1.png)

Although we are not using input3-5, they still need to have a name.

You can now create an instance like so to activate a model for a device and decide where the offset value is coming from on a case-by-case basis:

 ![Instances](https://europe1.discourse-cdn.com/flex005/uploads/cumulocity/original/3X/e/e/ee478dd41b5ac441e642a6524ea9201a4ab3967f.png)

## What to watch out for

### Don’t overuse

There are often multiple ways to wire the logic in your model, but some are more efficient and descriptive than others.

If you are working with numeric values and want to map certain ranges to certain values, chances are that you can use the **Range Lookup** block instead.

Similarly, if you want to use the **Selector** to output a `boolean` value, a combination of blocks from the **Logic** section might also do the job.

The **Switch** block is best used to control the flow of logic. In cases where you are just looking to use different values per instance, you might use _Template Parameters_ directly. And if you are looking for dynamic behaviour during _runtime_, the **Gate** block may let you express your logic more naturally.

### Use the correct type

The **Switch** block just passes its input through to its output. So all input ports _must_ have the same type, and this is also used as the output type.

For the **Selector** , you can control which type the parameters actually are by choosing the correct _Type_ parameter.

### Model Complexity

**Switch** can be useful for handling multiple cases in a single model. However, if these cases are generally independent of each other, it might be just better to create separate models. This also potentially reduces the performance overhead of blocks that are never used in the individual instances.

On the other hand, using **Switch** es might allow you to collapse multiple models into a single one - which makes it simpler to see generic patterns and reduces the cost of making changes.

## Summary

The **Switch** and **Selector** blocks are really helpful tools that let you express your logic more naturally and can replace complex if-then-else **Gate** logic in certain situations.

Want to read more? Check out other articles of this series [Blocks Explained](https://community.cumulocity.com/tag/blocks-explained)!