8 Things Every Salesforce Admin Should Know When Implementing Field Service

#1 The Essentials

Salesforce Field Service (formerly Field Service Lightning) is a bolt-on package to Salesforce Service Cloud that can be a powerful tool for an organization, with features such as appointment scheduling, time tracking, and inventory management. An implementation of Field Service can be a major change for an organization; attempting to release too many new features at the same time can lead to confusion, frustration, and headaches for both users and admins alike. When dealing with a complex package such as this, consider a phased approach. Think through the greatest pain points, as well as the key features that will bring the greatest value in the initial rollout. For example, the ability to generate work plans and work steps on a work order, or the ability for a technician to order parts, might be a benefit, but not necessary for the initial rollout. Ultimately, a phased approach will reduce confusion, increase satisfaction with the system, and lead to a more successful, value-driven implementation.

#2 The State of the Data

For certain aspects of Field Service, such as inventory tracking and determining travel time between service appointments, having accurate, well-maintained data is critical. When dispatchers utilize the scheduler tool, having correct address information can reduce the risk of technicians being assigned to service appointments for which they are unable to arrive on time. If work needs to be scheduled at an account for which there is no address or a poorly formatted one, Field Service will not be able to properly calculate the travel time between that appointment and the one that came before. For inventory tracking, the business might have a desire to track the preventative maintenance for specific pieces of equipment installed at customer accounts. However, if the business does not have accurate data that shows which equipment is installed at which customers, how will Salesforce be able to properly track maintenance without accurate asset data? Prior to getting too deep into an implementation, it is critical to understand the current state of the data, and the effort make the data more actionable.

#3 Factor in Time for Data Requests

Much of the core functionality in Field Service is powered by reference data, which should be considered early in the implementation. Having the right reference is critical to ensuring Field Service works as intended. Some information, such as service resources, service territories, and work types, will need to be provided by the business. Depending on the volume of information needed and how it’s currently stored, these requests can take a significant amount of time. As such, request this data early in your implementation and ensure you clearly communicate the desired format – potentially providing a template. Some objects, such as work types, might be a new concept for the organization. If so, collaborate with the business to build out the list of which work types are needed. Depending on the organization, this could take a few working sessions to accomplish.

#4 Have a Strategy for Loading the Data

Depending on the volume of reference data needed, loading that data into Salesforce can present a challenge, and should be carefully planned. Consider a third-party data migration tool to assist with these data loads. Third-party vendors such as Flosum, Copado, and Gearset, have data tools with the ability to migrate data while taking into account complex relationships between objects. For example, instead of using data loader to first insert Service Resources, then Service Territories, then Service Territory Members, tools like the ones mentioned above can move all of them at the same time while keeping the relationships between records intact. This can be a significant time saver, not just for the initial implementation, but also when maintaining the system on an ongoing basis. For instance, when developer sandboxes are refreshed, having a tool to quickly seed those sandboxes with the appropriate reference data prevents admins from having to spend hours getting their sandbox ready for development. If a third-party data tool is not an option, carefully plan out the order in which object records should be loaded and save templates of what should be stored in the data load for each object, which will save admins time when further data loads become necessary.

#5 Downstream System Impacts

In addition to Salesforce, a company might also use a plethora of other enterprise systems for various aspects of their operation, such as billing, time tracking, or inventory management – all of which might need to communicate with each other. For example, it might be desirable for the service team to have the ability to order products required to complete their work orders; however, what if Salesforce isn’t the system of record for products? Understanding where the product list is maintained, how its kept up-to-date, and how the data gets into Salesforce is crucial to ensuring technicians will be able to search from an accurate list when submitting product requests. What about billing systems? Are there billing processes handled in an ERP system that are dependent on actions taken in Field Service? Regardless of the organization, understanding the big picture of where Field Service fits within the larger ecosystem and the integration patterns that must be kept intact will lead to better implementations and reduce the risk of breaking downstream processes.

#6 Affected Groups

Field Service teams do not operate in silos. They are an important part of the customer journey that involve many other groups. Before diving into development, take time to understand the process of how and when work gets scheduled. Perhaps work gets scheduled when a customer contacts customer support regarding an issue with previously installed equipment, or work may need to be scheduled for installations after an opportunity is closed won by the sales team and approved by an engineering team. Both scenarios involve different groups that should be considered. If your Field Service implementation involves product ordering or inventory tracking, is there a warehouse team or purchasing team that should be considered? If Field Service is implemented without a well-rounded understanding of the needs of other, potentially impacted groups, this can create unwanted disruption to the organization and lead to a significant amount of rework that could have been avoided.

#7 Beware the Limitations of the Field Service Mobile App

A core pillar of Salesforce Field Service is the Field Service mobile app, which can be a powerful tool if used properly. The app is designed to allow technicians to quickly access and take action on Field Service records. With geolocation tracking, dispatchers can view the location of technicians logged into the app, making it easier to identify the proximity between technicians and work that needs to be scheduled. Unfortunately, the app has many limitations in its ability to use flows, and does not currently support lightning components. If there is a desire to utilize a flow that shows the user a screen, there is a specific type of flow that must be utilized, called Field Service Mobile Flow. The limitations of this flow type include the inability to support dependent picklists and lookup fields within screens, as well as the inability to support invokable apex and certain types of actions. Creating a Field Service Mobile Flow that works on desktop and mobile is possible, but should be tested thoroughly in the app, as the debugger in flow builder does not always accurately represent how the flow will work in the app. The Field Service Mobile app is also limited in its offline capabilities, as only a portion of a user’s service appointments and related records get primed for offline use. The app’s offline capabilities should be clearly explained to business leaders and during end user training to prevent confusion after technicians start using the app. If service areas contain large portions that lack cell services, the value of the Field Service mobile app can be quickly eroded. Salesforce provides detailed documentation on the limitations of the Field Service app, which should be reviewed prior to planning any major customization to the app.

#8 Contractor Sharing Can Be Challenging

Not all companies have internal technicians for every region or type of work that they perform, and might rely on external contractors in these instances. Fortunately, external contractors can have access to Field Service functionality through Experience Cloud and the Field Service mobile app. However, in most instances, these external users should not have quite the same record access as internal service teams. Perhaps there is a desire to prevent technicians at one contracting company from seeing records owned by another, or perhaps they should only see records at accounts in which their contractor company is assigned. At the start of any project to implement Field Service for contractors, it is vital to understand what their record access should be. Due to the challenges around how sharing is configured in Experience Cloud, complex record access restrictions for contractors could potentially require apex sharing, which can add significant effort to your implementation. Work with the business to understand if access can be more open to prevent the need for custom apex sharing, and if that’s not the case, find out as early as possible.