Let’s think of you as a support agent. You get a call from a customer asking for an appointment for some questions he has on the case and wants to talk with the case owner. So what can do you What will you do in this “case?”
Salesforce Scheduler can help you in this “case”. Let’s drill down on what all we need to accomplish this:
- Case owner as a Service Resource
- Case reference to Appointment
- A flow
- Quick action on Case to initiate the flow.
A logical flow of the approach we will take in this use case will look like the following:
Get Case Details
Since this flow will run on the case, we need to get the details of it. First, we can set the “recordId” input parameter to get the current case, automatically giving us the case Id. Then, using this variable, we can query the case using the “Get Records” element in the flow.
Note that we need AccountId to map it to the ParentRecordId of the Service Appointment. OwnerId is needed to get the related Service Resource.
If we want to tag the current CaseId, we can create a new lookup on Service Appointment. A custom field is needed since Service Appointment can only support Account, Lead, and Opportunity except for Case! To ensure that value is populated in that lookup, we can override the JSON we pass in the final Save Action defined in the flow. For more details, you can refer to the blog here: https://unofficialsf.com/build-your-own-appointment-review-screen/. For now, we can skip it.
Get Service Resource
If we want to set the case owner as of the person who will work on this case, we need to make sure that he is a service resource. For more details, please check this help doc: https://help.salesforce.com/s/articleView?id=sf.ls_create_resources.htm&type=5.
To fetch the service resource, we can add the “Get Records” element like below. In this, we are fetching Service Resource based on Case OwnerId.
Scheduler flow allows you to filter the resources based on the list of Ids you pass to it. You can read more details here: https://help.salesforce.com/s/articleView?id=sf.ls_enable_service_resource_filtering.htm&type=5.
We can leverage this functionality for our use case. Since we want our case owner to be the Service Resource, we can add the Service Resource Id from the previous step to filterByResourceIds. Additionally, we can make anonymous booking as true and resource booking as false. This will make sure that we skip the OOB triage screen and resource selection screen.
The advantage we get from this is if the case owner is not a Service Resource, existing logic will fetch any available resource anonymously. You will not have to worry about resource selection. End to end experience will be very seamless for the agent who is booking that appointment.
Once all the nodes and assignment is done, you can test the flow using the “Debug” option and activate it once it’s working as expected.
After this step, it’s up to you how you want to distribute the flow. For this blog, we are using Case Action to create a new appointment. Since the “recordId” flow variable is set for “Available for input” in the flow, this action will automatically set it to the current record on the detail page.
You can add this action to the case layout. The end-to-end flow should work something like this:
We have added all the metadata to this git repo for your reference. Please feel free to deploy it to your Sandboxes and try it out! Link: https://github.com/snathpatil/case-appointment-booking
Note if you’re looking for a virtual advisor then do have a look at this blog: https://unofficialsf.com/tele-or-virtual-scenarios-using-salesforce-scheduler/
Scheduler is not to be positioned in cases where the Service Resource is travelling to a customer’s location