The Future of Salesforce Field Service Lightning – and Current Limitations

Share this article...

During 2019, a number of breakthrough improvements were made to Salesforce Field Service Lightning (FSL) around optimization, timesheet automation and enhanced matching rules. These updates hinted at Salesforce laying the groundwork for a solid program of product enhancement, offering further proof of how much potential Salesforce see in the product.

So far in this series, we looked at how Field Service Lightning projects are structured, and how to avoid dropping the ball during the initial scoping phase. Now, we’re going to look at where FSL stands as a workforce management tool, and speculate on how current limitations could potentially be addressed in the (near) future.

1. Shifts

Up until now, organizations with a shift system were forced to navigate the complexity of Service Territory Memberships. For example, you have a group of workers that switch between geographical regions, or between early and late shifts. Often it’s a balance to keep all the workers happy and if they’re being regularly given undesirable shifts then that’s likely to cause discontent.

The first cut of Shifts is in Beta for Spring 20’ and offers a combination of object model + interface which allows you to manage this process better. Both the shifts and the resources assigned to them can be managed. It’s an important step to alleviating the System Admin of some pretty arduous tasks after the FSL project go-live.

Source: Salesforce Spring ‘20 Release Notes

2. Scheduling Dependencies

Also in Beta this Spring, is the ability to create “Immediately Follow” Scheduling Dependencies. This will help in scenarios where a Work Order has multiple Line Items which should be completed in one visit.

There is real potential to improve dependencies in general – and some work is required if users are to be able to plot dependencies at scale, either manually or automatically. I view the current dependency component as something which will be replaced at a later date and the new dependency type in Spring 20’ shows that Salesforce are at least thinking about this aspect of the system.

Source: www.biswajeetsamal.com

3. Crews

Summer 19’ saw general release enhancements to the management of Service Crews, allowing for easier planning and execution of the Service Crews functionality at scale. It helps solve the lack of fluidity in maintaining transient crews by offering a sharp interface that enables the user to plan crew membership within a Gantt styling.

Source: Salesforce Help

Currently, crews work on the premise that all members have similar skills, which means that a Work Order cannot be matched against a mixture of skillsets. For example, if you want one electrician and one carpenter, then you’ll need to break them out into different Service Appointments and create same start dependencies between them. So it’s extra work for the user in some scenarios like professional services or complex engineering.

It would be amazing to see something in the future that catered for a blend of skills on the same appointment in a more dynamic setting – but outside of the Crews functionality.

4. Capacities

For large organizations, customers cancelling appointments is a big problem. If you’re doing millions of service appointments per year, a 5% cancellation rate is significant enough to consider a large-scale customization of the product. In this scenario, a custom airline-style ‘overbooking’ system can provide the solution but is effort-intensive.

Salesforce had their first foray into capacity based booking by Work Type, a feature that was in Beta for Summer 19’ but was unfortunately pulled for Spring 20’.

Just because the first cut didn’t make it, doesn’t mean that the concept will disappear, so it’s safe to assume that the product team have taken the learning from the initial concept and are squirrelling away on a new approach.

5. Mobile App

Some larger clients opt for a custom mobile app over the native FSL mobile app – and that’s mainly down to the customizability.

Other workarounds I’ve seen have been to extend the FSL mobile app out into Salesforce Mobile via an app extension to handle the tasks that it cannot do.

At present, it’s fairly rigid in how you can develop it further, and with Salesforce’s mobile-first push, this year and next should be a big year for the mobile app. And if the product team are reading, can we have Lightning Components next, please?

Summary

In this article, we’ve looked at ways that FSL has developed over the past year and how it could transform during 2020. In the next articles, we’ll be getting into the technical aspects of Field Service Lightning that you may not find so easily in the documentation. Stay tuned!

One thought on “The Future of Salesforce Field Service Lightning – and Current Limitations

Leave a Reply