A Simple Answer to one of the most Frequently asked questions within the Salesforce Field Service Application.

As a Field Service Expert, I have numerous opportunities to support Partners and Customers through the implementation and enhancement of Salesforce Field Service as well as educating them on Field Service functionality best practices. One of the most frequent questions of Field Service Partners and Customers pertains to managing Operating Hours and the Appointment Booking Process.

In order to provide you with a full explanation, let’s first set the stage with an example of the requirement and the criteria:

Service Territory: Chicago

Time Zone: CST

Operating Hours: Monday — Friday 8 AM — 6 PM

Desired Outcome for Appointment Booking: As a Customer Service Agent is working with a Customer to schedule an Appointment, they want to provide 2 Hour availability windows for the Customer to select from.

In this scenario, the customer service agent would present the customer with several two-hour availability windows within the range of the overall Territory Availability. For example: Monday, 8 AM — 10 AM, 10 AM — 12 PM, 12 PM — 2 PM, etc… Tuesday, 8 AM — 10 AM, 10 AM — 12 PM, 12 PM — 2PM, etc.…

Steps for Configuration

The first step would be to create an Operating Hours Record with the Slots outlined in the example and below is a screenshot of what that looks like through Field Service Guided Setup.

You can also create the Operating Hours Record and Slots directly from within the Operating Hours tab itself, but regardless of which path you choose, the end result should align to the availability windows you are looking to provide when going through the Appointment Booking process. So far so good!

Next, you want to identify the Operating Hours record you created above within Field Service Settings > Global Actions > Appointment Booking. This is what provides the Scheduling Logic with a default value to use for Appointment Booking, specific to the availability windows that are presented. Again, I’ve included a screenshot below of making this selection in the Field Service Settings. So far still good!

Now, this next step is where I see Partners and Customers alike go down a path that isn’t recommended and can definitely have an impact on overall scheduling logic performance. When configured incorrectly Service Territory Operating Hours may be hindering overall scheduling logic performance and may result in some inconsistent timeout errors when trying to book Appointments.

So, what is the common misconception? More often than not I see the Partners and Customers navigate to the applicable Service Territory and assign the same Operating Hours record for the availability windows as their Territory Operating Hours Value. I’ve included a Screenshot below showing this type of setup.

Now, I know what you might be thinking, “what’s wrong with that? I mean the Operating Hours for the Territory are supposed to be 8 AM — 6 PM and if I assign those Operating Hours to the Territory, it looks right to me when viewing the Gantt. What gives?

Wait, are you telling me it is a better practice to create another Operating Hours record for Monday — Friday with a single 8 AM — 6 PM slot each day?”

The answer is easy. Yes, I am!

Below is a screenshot of the recommended approach creating an Operating Hours record, directly from the Operating Hours tab, with a single Slot to represent actual Territory Availability each day. You could also create this using the Guided Setup as outlined in the first example further above. Once created you would relate to the Service Territory directly through the Operating Hours lookup on the Service Territory Object.

The ‘Why’ behind the Recommendation

General Considerations

A general consideration is the simple fact that you are completely linking your overall Territory Availability to the availability windows you are wanting to present as part of Appointment Booking.

I do concede that in most cases this is probably not an area of concern as most Customers do attempt to align those two things. However, consider the use case of wanting to update Territory availability to start at 9 AM each day vs 8 AM? In that scenario, the first availability window of 8 AM — 10 AM is still a valid option even though the earliest a Technician might be able to get to an Appointment would be 9 AM. The result is that instead of simply updating your Territory Availability to start at 9 AM, you now have to edit all the individual slots to reflect the 2-hour availability windows starting at 9 AM, since you are working off of a single Operating Hours record for both.

Now again, I’m not saying that would be a common setup but using the same Operating Hours record for both the availability windows AND the Service Territory availability would mean that every time you potentially have to adjust Territory availability, you will also be adjusting the availability windows as well.

Another general consideration to keep in mind is the fact that the availability windows define when a job can start, not necessarily when a job can finish. This can be important when considering the notion of extended hours for the overall Territory Availability. So even though extended hours weren’t part of the original example, it is still a common use case within Field Service and needs to be taken into account. So, while you only want availability windows between 8 AM — 6 PM, what if there is a need to create extended hours from 6 PM — 7 PM each day? The use case could be just to ensure that a Technician can in fact start a job within regular hours but finish that same job after hours. That scenario becomes challenging to support if your availability windows and Territory Availability are being driven from the same Operating Hours record as the job will need to both start and finish before 6 PM.

Performance Considerations

Now, let’s get to the potential performance considerations, which I’m sure you’re definitely more interested in.

When the Scheduling Logic runs it will iterate over each Service Territory Availability Slot to determine what availability windows are presented back to the user. Why is that important you ask? Well, let’s dive into that a bit more.

So, in the recommended path, meaning having a Territory Operating Hours of Monday — Friday with a single 8 AM — 6 PM slot per day. The Scheduling logic does the following: (Assuming just a single resource across a standard 5-day work week)

Queries for the Territory Availability Slots, which the result of that query being 5, one for each day of the week. So, a total of 5 iterations to determine the appropriate availability windows.

Now, let’s consider the alternative, which is still a common setup that I see all the time in using the same availability windows as the Service Territory Operating Hours record. The scheduling logic does the following: (Assuming just a single resource across a standard 5-day work week)

Queries for the Territory Availability Slots which the result of that query being 25, five slots for each day of the week. So, a total of 25 iterations to determine the appropriate availability windows.

Just think about that for a second, even though I’m just considering a single resource and 5 days of availability, the scheduling logic is having to iterate over 5 TIMES as many records when using the same availability windows for the Service Territory Availability. Now think about 25 Resources in a Territory over the course of 10 days of availability and still having to process 5 TIMES as many records? Yikes!

The end result could be time out errors in the Appointment Booking process without really a clear understanding of why the Book Appointment action is not able to process the availability windows or present back the expected result when attempting to schedule.

Conclusion

You can really start to see the potential impact in performance, which can be completely avoided by simply creating a 2nd Operating Hours record to represent the whole of the Territory availability vs using the same Operating Hours record for both the availability windows and the overall Territory availability. So, let’s all minimize that strain on the Scheduling Logic as well as minimize potential time out errors when attempting to book Appointments!

Author

Steve Hupp, Field Service Practice Leader at Slalom

Steve is a Field Service Leader and former Salesforce Employee who worked across various roles within Solutions Engineering and Customer Success. He has over 4 years of experience in the Salesforce Platform and over 3 years of experience dedicated to working with the Salesforce Field Service Product. He is extremely active in the Salesforce Field Service Communities and has a passion for sharing knowledge as well as positively influencing the overall success of the Salesforce Field Service product.

Additional Contributions from:

Jael Noda Molina, Field Service Subject Matter Expert at Slalom

Adriana Seastrom, Field Service Subject Matter Expert at Slalom

Bobby Vadakkel, Field Service Subject Matter Expert at Salesforce

Want to know more?

Learn more about Slalom’s Field Service Expertise by visiting our AppExchange listing here and checking out the ‘Featured Resources’ Section

Learn more about the Slalom Salesforce Practice here

Connect with the Author directly on Linkedin or email directly at [email protected]