We are building a custom scheduling solution and are planning to use the Nylas Scheduler.
In front of the scheduler, we have a custom routing engine that determines a subset of contacts (e.g. sales reps) that should be eligible for a given scheduling request. Based on that routing decision, we need to render availability and allow booking with that specific subset of participants.
To make this work with the Nylas Scheduler, our planned approach is:
Check whether there is an existing scheduler configuration matching the selected list of participants
If not, create a new scheduler configuration on the fly and use it for scheduling
My main concern with this approach is the potential number of scheduler configurations we might end up creating over time, especially in enterprise-scale setups.
I wanted to ask:
Are there any practical or documented limits on the number of scheduler configurations per account?
Is creating scheduler configurations dynamically/on the fly considered an acceptable or recommended pattern?
Are there alternative architectural approaches you would recommend when the exact list of participants is not known in advance?
Any guidance or real-world experience would be much appreciated. Thanks!
1 - No documented limits on configuration count exist
2,3 - Please take a look at using (max-availability or max-fairness event types) with one configuration containing all possible participants, documentation:
Please let me know if this will solve your use case.
I think the key part of our use case may not have been clear. Our main requirement is per-request participant scoping.
Specifically, for each scheduling request we have a routing step that decides which subset of users is eligible. For example:
All possible hosts: A, B, C, D, E
Request #1: routed to {A, B}
Request #2: routed to {C, D, E}
When rendering the scheduler for request #1, availability must be computed only from A and B. For request #2, only from C, D, and E.
From what I understand, with max-availability / max-fairness event types the scheduler always considers all participants defined in the configuration, and there is no way to dynamically restrict that list per render.
If that understanding is correct, then round-robin works well when all participants are always eligible, but not when eligibility is request-specific.
That’s why we are currently considering creating or reusing scheduler configurations per routed participant set. Please let me know if I’m missing a way to scope participants dynamically at render time.
You are correct. The Scheduler API does not currently support dynamically scoping participants at render or availability request time. Availability is always computed using all participants defined in the configuration.
The only case where participant filtering occurs is during rescheduling for round-robin bookings, where the system restricts availability to the originally booked participant. However, this does not apply to your use case.
Option 1:
Create or reuse a Scheduler configuration for each routed participant set. This maintains access to all Scheduler features like booking management, UI, and notifications. Configurations can be pre-created if sets are known or generated on-demand and cached.
**Option 2: **
If you need fully dynamic participant filtering without using Scheduler features, the Calendar API allows you to specify participants in each request. This gives full control but requires building your own booking logic and UI. { “start_time”: 1234567890, “end_time”: 1234567899, “duration_minutes”: 30, “participants”: [ {“email”: “``hostA@example.com``”, “calendar_ids”: [“primary”]}, {“email”: “``hostB@example.com``”, “calendar_ids”: [“primary”]} ] }
Thanks for the clarification, this confirms our understanding.
We do want to leverage the Scheduler UI and its built-in booking and notification capabilities, so rebuilding the flow on top of the Calendar API would be a significant trade-off for us. Given that, it looks like option 1 is the right approach for our use case.