Context and Use Case
Salesforce Field Service (formerly known as Field Service Lighting or FSL) provides a series of UIs that allow agents and dispatchers to schedule appointments. However, a common use case for organizations involves providing self-service scheduling for end users through a Community. This package provides a wrapper and UI that allows admins to embed self-service scheduling within a Flow.
Note: this package requires that you own and have already configured Salesforce Field Service, and that the resources you are scheduling are licensed as Technicians. The users of the Flow would be authenticated Community (Experience Cloud) users booking appointments with those licensed technicians.
HUGE thank you to Field Service experts and all-around wonderful people Laura Bode and Leigh-Anne Nugent for all their help making this a reality.
The star of the show in this package is a screen Flow called “Flow Scheduler” (aren’t I creative?) that is meant to be called as a subflow from within a larger self-scheduling Flow. This subflow is all you really need to understand in order to use this package and doesn’t require any modification, but I’ll also explain the underlying components below for anyone interested. The package also contains two custom checkbox fields, one on Service Territory and one on Scheduling Policy, each called “Default for Flow Scheduler”.
This screen Flow takes two input parameters, a required Service Appointment ID and optional Scheduling Policy ID. It then displays a list of available slots to the user, and schedules the Service Appointment based on the user’s selection. Finally, it returns two values, the start datetime and end datetime of the user’s selected slot.
- The Service Appointment ID is always required, and must be created earlier in the Flow or passed in as input.
- The corresponding Service Appointment must have a Service Territory associated with it unless you have checked the “Default for Flow Scheduler” checkbox on a Service Territory record.
- The Scheduling Policy ID is required unless you have checked the “Default for Flow Scheduler” checkbox on a Scheduling Policy record.
- You can then use the startTime and endTime output values (both of which are of type datetime) and use them
Next we’ll explore what’s actually happening inside the Flow Scheduler subflow.
Action #1: Get Slots
This action is an invocable Apex wrapper that calls the AppointmentBookingService.getSlots() methods. It takes two parameters:
- Service Appointment ID (required)
- This action assumes that the Service Appointment has already been created and is being passed into this subflow from the parent flow. See the sample build for more detail.
- Scheduling Policy ID (optional)
- If this input is not provided, the method will look for a Scheduling Policy record with the “Default for Flow Scheduler” checkbox checked. If it doesn’t find one, it will throw an error.
The action returns one of two values, either:
- a list of an Apex-defined type called BookingSlot, which will be passed into the Display Available Slots screen component, OR
- a string value containing the error message returned from Apex. The goal is not to get this one.
Screen: Display Available Slots
This screen contains the UI component called Display Booking Slots that displays the list of available slots to the user. It takes as inputs the two values returned by the Get Slots action. Again, only one of these values—the list of slots OR the error message—will have a value.
It returns as output two values: the start time and end time of the slot the user selects. Both are of type datetime.
If you want to customize the UI, you can modify the Display Booking Slots component (LWC) or build your own.
Action #2: Schedule Appointment
This action is an invocable Apex wrapper that calls the ScheduleService.schedule() method. It takes four parameters:
- Service Appointment ID (required): the same Service Appointment ID we passed to the Get Slots action.
- Arrival Window Start Time (required): this is the start time that the user selected from the Display Booking Slots component.
- Arrival Window End Time (required): this is the end time that the user selected from the Display Booking Slots component.
- Scheduling Policy ID (optional): Once again, if this value is not provided the system will search for a Scheduling Policy record with the “Default for Flow Scheduler” checkbox checked.
This action does not return a value, it simply schedules the Service Appointment.
Stay tuned for a detailed demo video coming soon!