How a Host Is Chosen
The order of decisions, what counts as busy, and what each sharing strategy actually does.
This is the full account of how a group calendar picks a host. It matters because two of the three strategy names suggest behaviour slightly different from what they do, and because the order of the steps — availability first, sharing rule second — is what makes the whole thing safe.
If you only remember one thing: a sharing rule chooses among members who are already known to be free. It never decides whether someone is free.
The order of decisions
| Step | What happens | If it fails |
|---|---|---|
| 1. Build the eligible list | The calendar's owner, if the owner takes bookings, followed by every selected member. Duplicates and placeholder entries are dropped. | If the list would be empty, the owner is used anyway — a group calendar is never left with nobody. |
| 2. Honour an explicit choice | If the schedule allows member selection and a specific member was requested, that member is checked for that slot. | If that member is busy, the booking is refused. It is not passed to someone else. |
| 3. Filter to the free | Each eligible member is checked against their commitments for that exact slot. Only those genuinely free survive. | If nobody is free, the booking is refused with a message that no team member is available. |
| 4. Shortcut for one | If exactly one member is free, they take the booking. | The sharing rule is not consulted at all. |
| 5. Apply the sharing rule | With two or more free, the strategy chooses between them. | An unrecognised strategy behaves as sequential. |
Important: Step 3 is why a group calendar cannot double-book. Availability is re-checked at the moment the booking is made, not when the page was loaded — so if someone else took the slot in between, the booking goes to another free member, or is refused if there is none. A refusal here is the system protecting you, not a fault.
What counts as busy
Meetings they organise
signal
optional
Anything the member created or is the organiser of, on any calendar.
Events on calendars they own
signal
optional
Their own calendars' events block them here. This is what makes a member's personal commitments protect them on a shared calendar.
Meetings where they are the host
signal
optional
Including bookings allocated to them on other group calendars, so a member cannot be allocated twice at the same time by two different calendars.
Every occurrence of a recurring commitment
signal
optional
A weekly commitment blocks its slot every week, not only the first.
Tip: The quality of allocation depends on members keeping their calendars current. Zyntro can only see commitments it knows about. A member whose real week lives in a calendar elsewhere will look free and be allocated bookings they cannot take — which is what connecting their own calendar is for.
The three strategies
| Setting | What it actually does | When to use it |
|---|---|---|
| Round robin | Picks the least busy of the free members: fewest upcoming bookings on this calendar. If two are level, the one whose diary is clearest furthest out; if still level, list order. It is load balancing derived from history, not a strict turn-by-turn rotation. | A team sharing work evenly. The right default for most group calendars. |
| Random | Picks any one of the free members at random, with no reference to load. | Evening out over a high volume of bookings, or deliberately avoiding a predictable pattern. |
| Sequential | Takes the first free member in list order. Because the list begins with the owner, this means the owner whenever the owner is free and in the rotation, then the next member, and so on. | A deliberate order of preference with automatic fallback — a senior person takes what they can, others cover the rest. |
Warning: Round robin will not look like a rotation, and that is correct. Because it balances on load rather than turns, a member returning from leave with an empty diary can take several bookings in a row until they are level with everyone else. Judged over a month it distributes evenly; judged over three bookings it looks arbitrary.
What round robin counts
Only this calendar
— Load is measured from bookings on the calendar being booked. A member who is busy on another group calendar is correctly seen as busy for availability, but their bookings there do not count towards their load here.
Only upcoming
— Past bookings do not weigh on the comparison, so load reflects the commitments ahead rather than history.
Not cancelled bookings
— A cancelled booking stops counting, so a member whose meeting was cancelled becomes a candidate again.
Warning: Allow Booking with Specific Member has no effect on a booking page or a form, as of October 2026. The booking page offers no way to choose a person, and a booking made through a form sends no preference, so the strategy always decides. The setting does work where a booking is created through Zyntro's Create Event API, which accepts a member. Treat it as an API-level capability for now rather than something your visitors will see.
Info: Two different people can hold the same slot on a group calendar. Zyntro only treats a booking as a duplicate when the same contact books the same calendar at the same time — deliberately, because pooling a team means one slot can genuinely support as many bookings as there are free members.
