> ## Documentation Index
> Fetch the complete documentation index at: https://80x.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Round robin

> The Round robin block picks one workspace member from a configured set, cycling through the set across workflow runs.

The **Round robin** block picks one workspace member from a configured set, cycling through the set across workflow runs. A round robin is a rotation: it hands out the next item in turn, then starts over once it reaches the end. This block only selects a user. It never writes that selection anywhere. So you pair it with a write block, such as [Update record](/reference/records/update-record) or [Create task](/reference/tasks/create-task), to act on the pick. The block remembers where it left off between runs. That memory is what gives each run the next member in turn, instead of a random repeat.

| | |
| - | - |
| **Category** | Workspace |
| **Credit cost** | Free. Logic blocks consume no credits. |
| **Engine** | New Workflows engine (June 2026+) |
| **Plan availability** | All plans |
| **Limits** | None documented. |

## Inputs

| Input | Type | Required | Default | Notes |
| - | - | - | - | - |
| Users | List of workspace members | Yes | None | The members the block cycles through. Order the set deliberately; rotation follows it. |

## Outputs

| Output | Type | Example | Notes |
| - | - | - | - |
| Picked user | Workspace member | Priya Sharma | The single member selected on this run. |
| Picked user's email | Email | [priya@acme.com](mailto:priya@acme.com) | The selected member's email address, ready to reference directly. |

Reference the selected member downstream as `{{ steps.round_robin.picked_user }}`, and the member's email as `{{ steps.round_robin.picked_user_email }}`.

## Behavior

The block keeps a pointer that marks whose turn is next. It advances that pointer each time it runs. On the first run it returns the first member in the configured set. On the next run it returns the second, and so on. After the last member, it wraps back to the start.

This pointer persists across workflow runs. It does not reset on each run. That is why two leads that arrive one after another route to two different members. Spreading the work this way is the whole point of round-robin assignment.

The block selects exactly one member per run, and it writes no record of its own. Wire the picked user into a following block to assign an owner, set a task assignee, or address a notification.

The configured set is a fixed list of members. The block does not check whether a member is out of office, over capacity, or otherwise eligible. It simply returns the next entry. If you need to route only qualifying leads, filter the run before it reaches the block.

## Gotchas

* **The assignment never lands.** The block picks a member but writes nothing. If you stop here, the owner field stays empty. Follow the block with [Update record](/reference/records/update-record), [Update list entry](/reference/lists/update-list-entry), or [Create task](/reference/tasks/create-task), then map the picked user into the relevant field.
* **A departed member still gets leads.** The set is a static list. A member who has left the team keeps their turn in the rotation until you remove them. Audit the configured set whenever the team changes.
* **Unqualified leads consume a turn.** Every run that reaches the block advances the rotation, even for spam or out-of-territory leads. This silently skews the balance. Put a [Filter](/reference/conditions/filter) before the block so only qualified records reach it.

## Examples

### Assigning new leads to a sales-development pod

A [Record created](/reference/triggers/record-created) trigger on the People object reaches the block. The block rotates through the sales-development representative (SDR) pod and hands the pick to [Update record](/reference/records/update-record).

| Field | Value |
| - | - |
| Users | Priya Sharma, Marcus Lee, Dana Okoye |
| Downstream block | Update record |
| Field updated | `owner` |
| Mapped value | `{{ steps.round_robin.picked_user }}` |

Result: the first new lead is assigned to Priya Sharma, the next to Marcus Lee, the third to Dana Okoye, and the fourth wraps back to Priya Sharma.

### Rotating a follow-up task across an account team

First, a [Filter](/reference/conditions/filter) keeps only deals above \$50,000. The block then selects the next account executive. A [Create task](/reference/tasks/create-task) block assigns the follow-up to that person.

```json theme={null}
{
  "round_robin": {
    "users": ["Priya Sharma", "Marcus Lee", "Dana Okoye"]
  },
  "create_task": {
    "assignee": "{{ steps.round_robin.picked_user }}",
    "content": "Follow up on Acme renewal within 24 hours"
  }
}
```

Result: each qualifying deal creates a follow-up task assigned to the next account executive in turn, so the workload spreads evenly across the team.

## Source

[Attio Workflows block library](https://attio.com/help/reference/automations/workflows/workflows-block-library). Last reviewed against the Attio Help Center, June 2026.

## See also

* [Celebration](/reference/workspace/celebration)
* [Permissions & workflow access](/explanation/permissions-and-access)
* [Round-robin lead routing](/guides/route-and-sequence/round-robin-routing)
* [Inbound routing by territory and seniority](/guides/route-and-sequence/territory-routing)
* [Attio Workflows block library](https://attio.com/help/reference/automations/workflows/workflows-block-library)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.