Source: https://cli.nylas.com/guides/round-robin-scheduling-cli

# Round-Robin Scheduling from the Terminal

Round-robin scheduling spreads incoming meetings across a team so no one rep takes every call. Products like Calendly charge per seat for it; you can build the same logic on the Nylas CLI in a script. Check each member's free/busy, pick the next available person by your own fairness rule, and book the event from their calendar. This guide builds a round-robin assigner from the CLI's availability and event commands, with the fairness logic in plain code.

Written by [Hazik](https://cli.nylas.com/authors/hazik) Director of Product Management

Updated June 8, 2026

> **TL;DR:** Round-robin scheduling is a loop: keep a rotation of team members, and for each request find the next person who's free with `nylas calendar availability check`, then book the event on their calendar with `nylas calendar events create`. The fairness rule — strict rotation, least-loaded, or first-available — is your code, not a vendor setting, so you control exactly how meetings are spread.

Command references used in this guide: [`nylas calendar availability`](https://cli.nylas.com/docs/commands/calendar-availability), [`nylas calendar find-time`](https://cli.nylas.com/docs/commands/calendar-find-time), and [`nylas calendar events create`](https://cli.nylas.com/docs/commands/calendar-events-create).

## What is round-robin scheduling?

Round-robin scheduling assigns each new meeting to the next member of a team in rotation, so the load spreads instead of piling on one person. It's how sales and support teams distribute inbound calls fairly. The two hard parts are knowing who's actually free at the requested time and booking on the chosen person's calendar — both of which the Nylas CLI handles across five providers.

Dedicated tools bundle this behind a per-seat subscription. Building it on the CLI keeps the rotation logic in your own code, where you can encode any fairness rule you want. The CLI supplies the calendar primitives — read free/busy, create an event — and you supply the policy that decides who gets the next meeting.

## How do you find the next available rep?

Find the next rep by checking availability in your rotation order until someone is free for the slot. `nylas calendar availability check --participants rep@x.com --start... --end... --json` returns whether that person is busy in the window. Walk the rotation, skip anyone busy, and stop at the first free member — that person gets the meeting.

Free/busy is the right signal because it's privacy-preserving and fast: it reports busy intervals without exposing event details, the same model Google and Microsoft use — Microsoft Graph exposes it as the [getSchedule](https://learn.microsoft.com/en-us/graph/api/calendar-getschedule) action. Checking five reps for a 30-minute slot is a handful of quick reads, so the assignment decision lands in well under a second. Persist the rotation pointer so the next request starts after the last person assigned.

```bash
#!/usr/bin/env bash
reps=("rep1@example.com" "rep2@example.com" "rep3@example.com")
start="2026-06-22T15:00:00Z"; end="2026-06-22T15:30:00Z"

pick=""
for rep in "${reps[@]}"; do
  busy=$(nylas calendar availability check \
    --participants "$rep" --start "$start" --end "$end" --json \
    | jq '[.[] | .busy] | any')
  if [ "$busy" = "false" ]; then pick="$rep"; break; fi
done
echo "Assigned to: $pick"
```

## How do you book the meeting on their calendar?

Once a rep is chosen, book the event on their calendar with `nylas calendar events create`, adding the requester as a participant and `--meeting-link` for a join URL. Because the event is created from the assigned rep's connected account, it appears on their calendar and the invite goes to the requester — exactly what a round-robin product does, minus the per-seat fee.

Advance the rotation pointer after a successful booking so the next request starts with a different person. The two CLI calls — check, then create — are provider-neutral, so a team split across Google and Outlook is handled by the same script. Keep the booking and the pointer update in one transaction so a failed create doesn't skip a rep.

```bash
# Book on the chosen rep's calendar and invite the requester
nylas calendar events create \
  --title "Intro call" \
  --start "$start" --end "$end" \
  --participants "requester@example.com" \
  --meeting-link

# Then persist the next rotation index so the next request rotates on.
```

## How do you change the fairness rule?

Change fairness by swapping the selection logic, since it's your code. Strict rotation always offers the next person in order; least-loaded counts each rep's events that day with `nylas calendar events list --json` and picks the lightest; first-available simply takes whoever's free soonest. The CLI gives you the data — busy blocks and event counts — and the policy is a function you write.

That control is the reason to build it yourself. A vendor's round-robin gives you a few preset modes; a script can weight by territory, skip reps who are on PTO, or cap daily meetings per person. Encode the rule explicitly so it's auditable, and log each assignment so you can prove the distribution was fair.

## Next steps

- [Find a meeting time](https://cli.nylas.com/guides/find-meeting-time-cli) — open slots across attendees
- [Calendly alternative for developers](https://cli.nylas.com/guides/calendly-alternative-developer-scheduling) — build scheduling on the CLI
- [Check calendar availability](https://cli.nylas.com/guides/check-calendar-availability-cli) — free/busy basics
- [Add conferencing to events](https://cli.nylas.com/guides/add-conferencing-to-events-cli) — attach a join link when booking
- [Full command reference](https://cli.nylas.com/docs/commands) — every flag and subcommand documented