Salesforce Scheduler: How to Architect for High Volumes
Salesforce Scheduler provides a precision scheduling experience, powered by APIs or flow, that allows you to schedule appointments and build stronger relationships with prospects, customers, and employees.
But what happens if you know you are going to be booking a lot of appointments? Like tens of thousands upward to over a million per month? From a volume perspective, that’s not a problem at all. The tool is built to handle large numbers of appointments. But it also means that you’ll have some architecture decisions to make.
The Time Slot call sits at the heart of Salesforce Scheduler. It represents the moment that your application gets the Time Slots that your Service Resource(s) are available to be booked. The image below shows an example of the output of the Time Slot call using an out-of-the box Salesforce Scheduler flow and screen component. Whether you’re leveraging Salesforce Scheduler flows or writing custom code that calls Salesforce Scheduler APIs to get appointment candidates, there are several important items to pay attention to, which we’ll review below.
Downstream Impacts
The reason we need to think about the Time Slot call as the heart of Salesforce Scheduler is because of the downstream impacts it has on other objects. As you can see in the data model below, available Time Slots (or Service Resource availability) have many associations: Service Resource, Service Territory, which is associated with Salesforce Events and/ or an external calendar, and so on.
Click here to download this data model from the template gallery on the Salesforce Architects Website.
Since Salesforce is based on multi-tenant architecture principles, you’ll also need to abide to governance rules. To stay within governor limits and ensure the best system performance, it’s important to observe the golden rule of Salesforce Scheduler, which is to limit your Time Slot Returns.
Limit Your Time Slot Returns
Regardless of how you’re leveraging Salesforce Scheduler, it’s important to limit the Time Slots returned to a maximum of 5000 Time Slots per call. When you are using Service Territories, this means 5,000 for each Service Resource per Service Territory for a single given Time Slot call. This translates to a recommendation to check availability for a maximum of 20 qualified Service Resources when using Shifts (a design where your Service Territories may be irrelevant). Qualified Service Resources are those who have the appropriate skill set and are associated with the appropriate Service Territory (where applicable).
Why 20 qualified Service Resources and 5,000 Time Slots per call? Well, normally using Apex and the REST API there’s a limit of 2,000 records that can be returned in a synchronous request. If you’re using Salesforce Scheduler, you get an increase to this limit.
We’ve tested up to 10k for Salesforce Scheduler. But while the platform will technically support that volume, just like with your bank account, it’s best to not spend everything with one go. Designing for 5,000 leaves plenty of room for error, ensures the best performance in terms of system response times and keeps you within the bounds of standard Salesforce Apex governor limits.
So now you know the two rules and why they’re important:
- Check availability for a maximum of 20 qualified Service Resources.
- Limit the Time Slots returned to a maximum of 5000 Time Slots per Service Resource per Service territory for a given Time Slot call.
Does that mean we’re done? Not exactly. Because of the impact to other objects, you’ll also need to pay careful attention to the way you architect your Salesforce Scheduler instance in order to set yourself up for success. Salesforce Scheduler is designed to be flexible, which means that there a lot of different levers you can pull that will tie back arithmetically to that Time Slot call.
How to Think About the Math
Your desired end result will be the 5,000 Time Slots per call we described in the last section, but the way you get to that number can vary. To ensure optimal performance of the Salesforce Scheduler engine, it is important to understand the balancing act and math and levers that you can adjust to bring about that end result. No matter how large or small, you should always keep the limits described above in mind to ensure best system performance and scalability.
- If you’re using Salesforce Scheduler APIs, the math is straightforward: you can code to only ever pull a maximum 5000 appointments.
- If you’re using flow, you’ll have to think about the related objects to ensure the math is set to design for a max of 5000 Time Slots per Service Resource per Territory.
One way you can do this is by being thoughtful (and possibly creative) when identifying Service Territories and their associated Service Resources. Make sure to configure them in a way that only allows your users to open a maximum of 5000 appointments for booking at a time for a given Service Resource at a given location/ Service Territory.
- For example, if X number of appointments can be taken in a given time slot (say 1 hr) and the location or shift operates for Y Hours (say 12 hours, resulting in 12 Time Slots) and appointment booking is allowed for Z days into the future, then the maximum value for X * Y * Z should not exceed 5000.
- If you’re using using Shifts, don’t exceed 4 Shifts per Service Resource per day. Also make sure not to exceed 20 qualified Service Resources per Service Territory, and make sure that your Time Slots are made available within 14 days. Note that “qualified” means Service Resources who are associated to the relevant Skills and Service Territories. Click here to read more detail specific to using Shifts.
All of the above will help ensure you don’t pull more than 5000 Time Slots per Service Resource per Service Territory per call. In the next section we’ll dive into other factors like the length or amount of appointments allowed in a day.
Ways to DECREASE the number of appointments (Time Slots) per call
So, you’re sold on the 5000 per Time Slot call “golden rule”, you’re using flow so you can’t hard-code a limit, and you’re wondering how to DECREASE the Time Slots you’re pulling in your calls. Here are a few things to consider:
- When using Service Territories, you can reduce the number of Service Territory Members (i.e., Service Resources) associated with each Service Territory. Reducing the load per Service Territory will help ensure the best possible system performance.
- Decrease your Operating Hours windows. This will reduce the number of appointment windows (Time Slots) available in a day, and, ultimately, per call.
- Leverage the Appointment Start Time Interval in Setup → Scheduling Policies to reduce number of appointments (Time Slots) made available and displayed for a given day. In the example we used in the last section, we made this equal to 1 hour.
- Consider lowering the Time Slot Preload Multiplier parameter in Time Slot screen component in your Salesforce Scheduler flow(s) from the default value of 2 to 1. This parameter works in 7 day intervals, so “2” queries 14 days of appointments, whereas “1” queries 7 days. (A Time Slot Preload Multiplier of “2” equals the 14 days we mention in the above section related to Shifts.)
- Use the “Time frame after” value (not to be confused with Start or End dates) on Work Type to create more space between your appointment Time Slots. There is a User parameter in the Salesforce Scheduler engine that, in turn, uses the “Time frame after” parameter as it works the magic to call Time Slots.
Here are some examples of the results that the above adjustments can be used to affect Salesforce Scheduler math:
Thanks for taking the time to read through this today! If this were Trailhead, you’d get a badge with super fun confetti, so let’s take a minute and pretend together that just happened. Confetti or not, you’ve just learned all of the ingredients for the secret sauce of architecting your Salesforce Scheduler solution for success, and have risen to the ranks of Salesforce Scheduler Superhero. Congratulations. Go forth and enjoy your day. Cape optional.
