This blog post walks through what developers may want to know when creating apps for Field Service Lightning. This blog post has a slew of concrete tips and best practices (including code samples) to help you build the best apps for your company’s teams in the field.

About the Authors

Rohit Kumar is Senior Consultant with Salesforce India Services Team and specializes in Sales and Service Cloud and is responsible for the design, development and deployment of applications on Force.com platform.

Payal Jain is a Senior Solution Architect at Salesforce and is focused on the design and architecture of business transformation engagements delivered by the Services team.

What is Field Service Lightning?

Field Service Lightning (FSL) is a Salesforce product that connects customers, dispatchers and service technicians on a single platform. When building on Field Service Lightning, your field agents can create and edit work orders, manage and monitor technicians, keep track of assets, schedule work, and monitor performance in real time.

We’ll cover a few common use cases that Field Service Lightning helps to solve. If you’re developing a field service solution, or looking to optimize your existing solution, we hope you’ll find some great tips and code.

Appointment reservations based on real time inventory checks in external systems

Appointments or field visits often need to be scheduled based on availability of inventory (needless to say, this is in addition to availability of technicians!).  How and where inventory is held is driven by your business model and needs- but from our experience it can be narrowed down to two patterns: inventory is either held in Salesforce, or in an inventory master that integrates with Salesforce to display a realtime view.

Your business use case may dictate that appointments be booked only once inventory is available, or is shipped to a specific location (for example to warehouses, customer premises, or service centers). In these scenarios, ensure your app accounts for that date of availability and optimize accordingly. The below code may help you inform case management or order journey to check on inventory (if in an external system) and drive appointment booking.

Tailor the code sample below for your needs.

Activity Templates for field appointments: Your checklists for successful field visits

It’s extremely valuable for technicians to have a checklist to use during field visits. When developing for Field Service Lightning, view it as an activity template that lists each activity item in sequence, providing guidance on what needs to be completed to successfully close a field visit, and how long each task should take. When designed well, these templates or checklists are powerful in-app references, reducing field errors and augmenting training.

We’ve found the below pattern works extremely well when your use case requires a particular set of tasks that must be carried out for specific appointment types (for example, Healthcare & Equipment Manufacturers).

To begin, try creating custom objects, for example Service Templates and Service Template Tasks. Then tie Service Templates to Service Appointment Types. For each Service Template, create a set of activities that need to be completed. A lookup relationship from Service Appointments to Service Template then brings Service Template Tasks forth to the service appointment with minimal customization.

Work Types could be leveraged out of the box when applicable in scenarios where work orders are used.

Appointment bundling:  What to consider

When designing your field service implementation, it is imperative to understand how field appointments are structured for your use case. Determining the functional entity that appointments are parented against is vital, as it drives the data model and relationships you build in your application.

Ask yourself the following questions:

1. How are your appointments triggered? Are they based on independent orders, service requests, or opportunities? For example, are your field visits based on specific orders from customers that need field work, or triggered by service requests?
2. Is it routine to run multiple appointments at the same site? For example, if you were in the business of servicing elevators, then a common scenario would be to have field visits onsite to service ‘all’ elevators.
3. Will you need to service multiple customer assets as part of one field visit?

Parenting of appointments should be architected based on your company’s answers to the above questions. Your business may have additional requirements, such as singular invoice generation, signature capture based on each customer asset serviced, or specific order fulfilment requirements that dictate or influence the structure of service management in CRM.

Salesforce1 as the Field Service Mobile App

We recommend you use our purpose-built field Salesforce service iOS and Android (Safe Harbor) apps for field service scenarios when possible. These apps are built for field service groups and we believe that these should work for most of your company’s mobile FSL needs. However, your business is unique.  It’s good practice to vet what is available, then see how it suits your needs. Map the available features to your business needs, understand scalability and maintainability constructs, and from there create your app.

While Salesforce1 is not purpose built for field service scenarios, it could be explored as an option particularly when you have a non-standard field service scenario.  You may need a specific pattern / flow that the dedicated native apps do not offer – perhaps when you need to change user interfaces on the fly and need to offer a different UI based on profiles. Examples include regional or language variants.

A pattern that we’ve seen work well is as follows:

? Use the Lightning App Builder to quickly build a one page app that could be surfaced within Salesforce1. The purpose would be two-fold:

1. To create an easily accessible view of appointments for your technicians and point them to key tasks that underpin field service for their role.
2. Create a ‘landing zone’ for technicians, saving them from wasting time by scrolling through unnecessary menu items (this design pattern can work more effectively serves better than SmartSearch)

? Use publisher actions to optimize steps / actions that must be completed by technicians in the field.

? Build skinny layouts and minimizing the number of unnecessary clicks and taps, thus optimizing time usage

This pattern is immensely flexible as it harnesses the power of the platform.  We recommend you use native apps when available, as they’ve been developed from the ground up with a deep understanding of industries and leading field service  practices.

Leveraging Salesforce APIs for Field Service

Automation around Service creation and Appointment Booking is a requirement in many FSL implementations. The FSL package provides an Apex API that can be leveraged in conjunction with Apex to help with appointment booking automation.  These APIs offer powerful means of creating appointments from third party applications and/or any customer facing apps, such as Force.com sites. Email Services (although not a recommended approach ) can also be leveraged to create Services through email requests.

The service could be scheduled programmatically as follows.

CKSW_SRVC. ScheduleResult method would return scheduling time and grade inside scheduling object.

The sample snippet above is for reference and should be taken as an outline of the possibilities the system presents.

While taking this route, it would be key to identify appropriate defaults (such as Scheduling Policy et cetera). If no defaults are provided, the system intelligently reverts to the defaults set within Field Service Administration.

To book appointments, AppointmentBookingService method can be used in a similar manner. This would return appointments slots for a service by specific calendar objects (which represents the appointment slots) and time zone for the calendar .

Method Syntax

CKSW_SRVC.AppointmentBookingService.GetSlots(ServiceId, PolicyId, Calendar, UserInfo.getTimeZone());

The business need would drive the pre/post processing logic that would need to be housed in Apex and hence this approach should be taken only as deemed appropriate over declarative techniques in the given business scenarios.

Note: The package name used here may change in the latest Spring release

Development Practices to keep in mind during a global roll-out

If your business is global and spans more than one region, it is imperative to carefully consider your foundation before rolling out the application.. While this document by no means covers all the dimensions you’d need to bear in mind, the following will give you a sense of what to consider in the earliest stages of planning.

Begin development with a global template in mind. Identify the common set of business processes and note differences. An approach that usually works well is to first build the framework / foundation for one country or region, then iterate additional countries (or whatever the unit of iteration may be for you). While building a solution be aware of the following (specifically relevant for engineering teams):

• Leverage custom settings, custom metadata and custom permissions wherever possible as opposed to hard coding values.
• Be mindful of using validation rules, formula fields that return text values, or are based on string operations.
• Do not rely on specific date and time formats.
• Interpret units of measure based on the region / country and do not hard code units in calculations / UI / reports.
• Make your Visualforce as locale aware as possible.
• Plan your email strategy early – you may need to support multiple languages. All client interaction including service confirmation notifications, service completion notifications and more will need to be sent in the correct language. The design approach you employ will be determined by how many email templates (multiplied by languages) you are dealing with. One way to approach this would be to have one template per language and use declarative techniques such as the Process Builder to branch appropriately based on the contact’s selected language. Alternatively, you could build a Visualforce framework to provide a sophisticated means to address this requirement.
• Be mindful of appointment and service bundling scenarios while designing the solution.
• If you plan on using Salesforce1, streamline the user journey based on primary user journeys and build towards a lean and clean single page app view (think publisher actions and Lightning App Builder).

We hope that you find these best practices and development tips useful when creating your Field Service Solutions. You can find out more from the links below, and if you have any questions or comments, post on the Field Service Developer Community!

Additional Resources

• Field Service Lightning Feature Demo – Field Service Feature Demo

• Field Service Lightning Guide – Help and Training Guide for Field Service Implementation

• Field Service Lightning License Details – Feature and License Details