Use Flows and Experience Cloud to Access Salesforce Scheduler.

Use Flows and Experience Cloud to Access Salesforce Scheduler | Automate This!

By

Welcome to another “Automate This!” In this live-streamed video series, we cover all things automation, from use cases and best practices to showcasing solutions built by Awesome Admin Trailblazers like you. With automation, you can remove manual tasks, drive efficiency, and eliminate friction and redundancy. In this episode, learn how Lynn Guyer requests support from a health care provider from a website.


Use case: Provider scheduling was manual, costly, prone to errors, and static in time

An allergy physician group contracts with a few hospitals in rural areas of the state to virtually see patients. The practice needs an automated way for the hospital to contact the provider scheduled on call. In the past, they used a call center, which was expensive and made a lot of mistakes when taking information. They also have many last-minute changes to the schedule and want the ability to update in real time instead of sending out a paper calendar for the whole month. In this blog, I explain why and how I used Salesforce Scheduler, Experience Cloud, and flows to automate this process.

The solution: Automate the support request from the health provider

Part 1: Salesforce Scheduler

After evaluating many scheduling products, I chose Salesforce Scheduler for the ability to have a unique time zone per user and to automate with Salesforce flows. Salesforce Scheduler is an add-on product. There are associated permission sets and licenses by user persona that can be assigned to full or Salesforce Platform users. Salesforce Scheduler contains a small number of objects from Field Service, and you can access it from the Salesforce Scheduler Setup app. You can also add the objects to other apps after permissions are granted.

The minimum objects in Salesforce Scheduler that require record setup to run are Service Territories, Work Type Groups, Operating Hours, Service Resources, and Shifts. Service Territory is any entity that needs a unique schedule. Work Type Group is what shifts are grouped by on the visually appealing weekly calendar view called Schedule List Display. I make them have a 1-to-1 relationship with a Service Territory to show schedules. Operating Hours are required by the Service Territory; as a result, I created the ones I need in my org.

Service Resources are the people working the shift in the Service Territory. They need to be associated with all the service territories they work shifts in. Service Resources are required to be associated with an active Salesforce user. Consider this when you think about the onboarding process and how many licenses you have available.

Finally, Shifts is my favorite object in this product. I made a custom field for shift type that I use to run flows, since the out-of-the-box type field is not editable. You can create Shifts without a Service Resource, which is helpful for schedule planning. You can also create Shifts to be reoccurring, but they need to have the same Service Resource for that repeating Shift.

I experimented with creating a template and uploading from Dataloader. (Note: My demo org screenshot below has full Field Service, so there are extra buttons not available in Salesforce Scheduler.) I also created a Service Territory for the on-call Salesforce administration/IT team. If anything goes wrong in the flows, the internal on-call person will get the record and figure out what to do with it.

Shifts shown by Work Type Group in Schedule List Display.

Part 2: Experience Cloud

An external facing site was needed for the contracted hospital to interact with. I included Salesforce Experience Cloud in the solution to provide this. The Experience site is able to interface with any piece of data inside Salesforce, including patient, customer, and schedule. Included in the org’s subscription, this was an economical solution. I created a (LWR) microsite to host the website. Since the current state of healthcare is short on employees, with many cycling in and out of units, the business needed a flexible way to make the site as open as possible to anyone who needed it. This was solved by making the site public to guest users to allow hospital workers in without usernames and passwords. With the high turnover at hospitals right now, this is necessary.

After creating the site, I updated the site guest user profile to include access to my custom objects. (Note: The link to this guest user is only available on the Settings page shown below. Be sure to bookmark or save the link for future use.) Since site guest users cannot have the Salesforce Scheduler permission set, I created a Hospital custom object as a pass-through object to connect to the service territories and access the service resource working a shift. I created a 1-to-1 relationship to each service territory for hospital records and related them to the Service Territory via a lookup field. I also added any other relevant information I would reference by hospital on the Experience Cloud site. In this case, I present the service-level agreement (SLA), so that is stored on the Hospital object.

Experience Cloud Site Settings page.

Experience Cloud Site Builder layout.

Part 3: Flows

I created a screen flow for the user to interact with on the Experience Cloud site.

Configured screen flow.

The screen flow has screen components containing fields the providers need the requesting hospital to provide, which will then, in turn, populate the Visit custom object. The flow starts by getting all the hospital records to display in the screen component in a collection choice set picklist. The next element is a screen where the user inputs all the patient data.

Screen flow intro screen.

Next, the flow creates the visit record using the data from the screen component. Then, the flow gets the newly created record and its associated hospital so this information can be displayed on the confirmation screen, the last element.

You can confirm the visit request record was created by displaying the owner as determined by the schedule and the SLA associated with the hospital.

Screen flow confirmation screen.

Note that you need to modify the access to the flow in order to display this flow publicly on the Experience Cloud site. Check the box for “Override default behavior”, find the profile that the site guest user is assigned to, and enable it in the profile.

Screen flow permission override by profile.

I used a record-triggered before-save flow to trigger after a visit record is created.

  1. This flow checks who is on call for the hospital and request type, and assigns the visit record owner. A before-save flow updates to the same record that triggered the automation.
  2. The flow verifies that hospital is on the record since it’s associated to the service territory that’s required for the schedule using a Decision element.
  3. If not, a Get Records element is used to lookup the internal service territory. The shift for the current time is looked up via a Get Records. Use an Assignment element to assign the record to the internal on-call IT person or admin to figure out where the record should go.
  4. If hospital is found, the Decision routes to Get the service territory that is related to the hospital record to use later on.
  5. Depending on the visit reason, the Decision element routes the request to the appropriate shift by custom shift type field.
  6. The next Get Records element gets the shift using the current running flow time.
  7. Another Get Records element, but this time it gets the related service resource that allows the related user to be assigned as the owner.
  8. The last element assigns the owner.

Record-triggered before-save flow.

The final flow in this process is the record-triggered after-save flow, which performs actions outside the triggering record. The org added the digital engagement add-on product with SMS text allowance, which makes a messaging action available in Flow Builder.

SMS action in Flow.

Note: The action references a “messaging template” in Setup that needs to be created first.

Messaging Templates page in Setup.

The template is sent to the mobile number on the owner’s user record, which was just assigned in the prior record-triggered before-save flow.

Record-triggered after-save flow with action.

Once the automation runs, the on-call provider receives the SMS message to their mobile number. The record link is included in the messaging template.

Text message alert on phone.

When the provider clicks the link in the message, the Salesforce app opens to the newly created visit record they were assigned to. They are able to respond to the visit using three quick action buttons. The provider knows who to ask for when they call the hospital to set up a virtual appointment.

Visit record via link from text in Salesforce App on phone.

Overall, the combined power of Salesforce Scheduler, Experience Cloud, and flows gave us the flexibility to structure the ideal solution setup for the physician group, hospitals, and providers. Using this solution, users can access what they need with minimal effort.

Resources

Want to see more good stuff? Subscribe to our channel!

SUBSCRIBE TODAY
Copy Files from One Object Record to Another.

Copy Files from One Object Record to Another | Automate This!

Welcome to another “Automate This!” In this live-streamed video series, we cover all things automation, from use cases and best practices to showcasing solutions built by Awesome Admin Trailblazers like you. With automation, you can remove manual tasks, drive efficiency, and eliminate friction and redundancy. In this episode, see how Eric Smith created a subflow […]

READ MORE