---
title: Pools
summary: 'A pool is a dynamic group of users defined by rules instead of an explicit list. The pool resolves to whichever users match the criteria right now.'
section: features
tags:
  - crud
  - telephony
  - routing
  - dynamic
updated: '2026-08-12'
---

> A **pool** is a dynamic group of users defined by rules instead of an explicit list. It resolves afresh every time it is evaluated, so somebody who starts matching the criteria tomorrow is in the pool tomorrow with nobody editing anything.

## Overview

A pool expresses *"everyone matching these criteria"* without maintaining the roster by hand. You write criteria like *"include the Sales group, filter to French speakers in Brussels"*, and add a new user to Sales tomorrow and they appear in the pool automatically. Use a pool for queues, multicasts, and call flow steps that should adapt as the team changes. Use a [Group](groups.md) instead when the roster is the source of truth and you want explicit control.

## What it does

A pool runs a **two-phase selection** every time it is evaluated:

| Phase | Logic | What it does |
|---|---|---|
| **Add to selection (Includes)** | OR / union | Casts the initial wide net. A user matches if they belong to **any** of the listed groups, tags, languages, or locations. |
| **Filter selection using** | AND / intersection | Narrows the candidates down. Only users who also match all filter criteria survive into the final pool. |

For example: *"include the Sales group, filter by French language"* resolves to every member of Sales who also has French set as their language.

![The pool edit page, with the add phase and the filter phase side by side](pools-images/two-phase-selection.png)

| Outline | Column | Logic |
|---|---|---|
| <span style="color:#34c759">Green</span> | Add to selection | Matches a user who is in **any** one of these. |
| <span style="color:#0a84ff">Blue</span> | Filter selection using | Keeps only users who match **all** of these. |

The two columns hold the same four criteria types, which is why the phase a value sits in matters more than the value itself.

The edit page shows a **members preview** that resolves the current criteria live as you make changes. Use it to verify your criteria produce the expected list before saving.

> [!NOTE]
> Filters are **AND across criteria types**, but **OR within a single type**. Selecting two languages (French + Dutch) in the filter means French OR Dutch. Selecting one tag and one language means that tag AND that language.

> [!WARNING]
> An **empty includes section** produces an empty pool. Without candidates from phase 1, phase 2 has nothing to filter. Always pick at least one Include entry.

Pools are consumed by **queues** (members become agents), **call flow steps** (Ring user / Dial steps target a pool), and **multicasts** (members receive the page). The pool's Usage tab lists every place it is referenced.

## See also

- [Queues](queues.md) - the most common consumer.
- [Groups](groups.md) - the static-membership alternative.
- [Tags](tags.md), [Locations](locations.md), [Languages](languages.md) - the criteria dimensions.
- [Multicasts](multicasts.md) - can target pools.

```yaml fields
name:
  label: Name
  tab: General
  hint: 'Identifies the pool in dropdowns for queues, call flow steps, and multicasts. Use a name that describes what the pool resolves to, like "French-speaking sales agents".'
description:
  label: Comment
  tab: General
  hint: 'Optional note about what this pool is for.'
```