How many staff can a Microsoft Bookings page have?

The documented numbers (as of September 2026)#

The services figure is worded as guidance rather than a hard stop, but plan around it. It matters when you build one service per person or per combination of people.

Where "31" comes from#

A 2022 Microsoft Q&A thread reported that the Graph bookingService API returned only 31 IDs in staffMemberIds, even though the service had 50 or 64 staff. The person asking later found the cause: listing all services returned 31, while getting one service by its ID returned the full list. The answer also restated the 100-staff limit.

Microsoft doesn't document that truncation, and we haven't tested whether it still happens. If you script against Bookings, the safe pattern is:

• Read a service's staff with GET /solutions/bookingBusinesses/{id}/services/{id}, not from the list call.
• Read the page's staff with GET /solutions/bookingBusinesses/{id}/staffMembers, which returns every staff member on the page whether or not they're on a given service.
• Follow @odata.nextLink whenever it appears; that's how Microsoft Graph signals another page of results.
• Keep to four concurrent requests per app and booking mailbox, the Bookings limit in the Graph throttling documentation.

Permissions for these calls are covered in Graph API permissions for Bookings.

Where "30" comes from#

A 2022 Tech Community post from a school reported that the staff drop-down in service setup wouldn't show more than 30 teachers, so they split parents' evening services to get everyone in. Microsoft didn't document a 30-person limit then, and doesn't now. The Assign staff page has been redesigned since; we haven't checked it with more than 30 people. If you hit a cap in the interface, check the service in a different browser and through Graph before restructuring.

If you need more than 100 people#

• Split by team, site or year group. Several smaller pages are also easier to run. The FAQ says each calendar "is maintained independently", with no consolidated view, so plan admin access up front. How an admin can open every Bookings calendar covers that.
• Split services by group within one page only if you stay under 100 people. A service with 60 staff is fine; a page with 120 isn't.
• Give each person their own link when customers always know who they want. The options are in giving each staff member their own link.

A large school running parents' evenings is the typical case: splitting by year group or department keeps each page under 100 teachers. The education guide covers the other decisions for school and university pages.

Microsoft Q&A has one report of a page holding 110 Guest staff without an error. The reply pointed back to the documented 100. Don't build on that undocumented behaviour; it could stop working at any time.

What we saw when testing (September 2026)#

On a service where customers can choose "Anyone", the public booking page asks the availability service for every staff member on that service. In our captures, those reads took roughly 0.3 to 1.3 seconds, at the slower end when we asked for several staff across a month. Long staff lists on one service mean more availability to fetch each time a customer moves to another month.

BookingsXP is independent and not affiliated with or endorsed by Microsoft.