Salesforce Field Service: What Data Does Scheduling Need?

Salesforce Field Service schedules with the master data it knows and nothing else. Before the scheduling engine assigns the first job, it needs six kinds of data: service territories with operating hours, technicians with their skills, work types with duration and requirements, the assets at the customer site, customer visiting hours and the technicians’ absences. If one of them is missing or out of date, the engine sends the wrong technician or sends them at the wrong time. Most of this data already exists in the company, spread across the ERP, HR and the dispatchers’ heads.

Whether Field Service is worth it for your field service operation at all is the topic of the first part of this series: Salesforce Field Service: is it worth it?. This part covers the next question: what has to be in place before scheduling starts?

Missing data leads to failed visits

Every one of these failed visits costs a trip, a technician day and usually a second appointment. And almost every one goes back to a piece of information that was missing when the visit was planned:

• Spare parts missing: nobody knew exactly which machine stood at the customer site and which part it needed.
• Machine not accessible: the times when the customer grants access were not recorded anywhere.
• Wrong technician: technician skills were not maintained, or not up to date.
• Technician not able to work: absences or restrictions were unknown to the planners.

Scheduling software does not change this by itself. It makes the gaps visible faster, because it automatically takes decisions an experienced dispatcher used to take from memory.

What data does Salesforce Field Service need?

Salesforce describes the objects in the Field Service core data model1. For scheduling, these six areas matter most.

Service territories and operating hours

A service territory is the area in which work is scheduled, usually geographic. According to Trailhead2, territories and operating hours are the foundation: without them the scheduling engine has no boundaries to work within.

Technicians become service territory members. The guidelines for service territories3 say each technician has exactly one primary territory, plus optional secondary territories for backup and relocation territories for temporary assignments elsewhere. Salesforce recommends up to 50 technicians per territory. The territory member record also holds the home base, for example the technician’s home address when they start the day from there. Without it, the engine calculates travel from the wrong place.

Technicians and skills

Every technician is a service resource. Their qualifications are skills, assigned with a level. According to Salesforce Help4 the level ranges from 0 to 99.99, and the company decides what each level means. A scale your service management already knows works best, for example the training levels you already use for your products.

The difference between recording and enforcing matters here. Only the Match Skills5 work rule makes sure that only technicians with matching skills are scheduled. A technician with no skills at all is then no candidate for any job with a skill requirement. That is intended, and it also shows how hard a data gap hits.

Work types

A work type is the template for a kind of job, such as annual maintenance, breakdown repair or commissioning. It sets the estimated duration and the required skills. Work orders inherit the skills of their work type. With ten well-maintained work types, nobody has to enter by hand on every work order who may take it. How a case becomes a work order with the right work type is covered in from case to technician.

Assets and locations

Assets are the machines at the customer site. Work orders can be linked to an asset, and assets can form a hierarchy, a machine with its assemblies. The technician then sees the asset’s history, and the back office sees which part fits which machine.

Locations are places such as warehouses, vehicles or customer sites. A service van is a mobile location with its own stock. How parts, warehouses and the ERP work together is a topic of its own and gets its own part in this series.

Customer visiting hours

Customers have their own times when a technician can reach the machine. In Field Service you record them as operating hours on the account. According to Salesforce Help6, each new work order takes them over as visiting hours.

Opening hours do not solve every access problem. When a machine has to be shut down for maintenance, the visit needs to be agreed with the customer. How to handle that in scheduling belongs in the next part of the series.

Absences

Resource absences block time in a technician’s calendar. Salesforce knows the types vacation, meeting, training and medical. According to Salesforce Help7, optimization does not assign technicians to appointments that conflict with their absences. That only works when vacations and training actually arrive in Salesforce and do not live only in the time tracking system.

Where does the data come from, and who maintains it?

Hardly any of this data is created in Field Service. So before go-live I set a leading system and an owner for each kind. As a starting point I suggest this split and adapt it to the company:

Data	Leading system	Owner
Service territories and operating hours	Salesforce	Service management
Technicians and skills	HR or training system	HR with service management
Work types	Salesforce	Service management
Assets at customer sites	ERP	Order management or commissioning
Customer visiting hours	Salesforce	Inside service
Absences	Time tracking	HR

The interfaces follow from this table. Maintaining assets and skills by hand in Salesforce works for a pilot and breaks in daily operation. How to decide which system leads between ERP and Salesforce is described on the page Salesforce integration.

Skills and absences are data about employees. Agree early with data protection and, where there is one, the works council which of them may go into Salesforce. The same applies to the new app features I describe in Field Service Mobile: guided flows and voice.

Analyse the failed visits of the last three months

Take the failed visits of the last three months in one region. Assign each one a cause: parts, access, skills, availability or something else. The cause with the most failed visits shows which data you need clean first. If there is no list of failed visits, that is a result too: then the metric that Field Service will later have to be measured against is missing.

Then check each of the six kinds of data: does it exist, where does it live, who maintains it? Once those questions are answered, it makes sense to set up scheduling itself. That is the topic of the next part of this series.

Sources7

1. 1Field Service core data model (opens in a new tab)developer.salesforce.com
2. 2Trailhead (opens in a new tab)trailhead.salesforce.com
3. 3guidelines for service territories (opens in a new tab)help.salesforce.com
4. 4Salesforce Help (opens in a new tab)help.salesforce.com
5. 5Match Skills (opens in a new tab)help.salesforce.com
6. 6Salesforce Help (opens in a new tab)help.salesforce.com
7. 7Salesforce Help (opens in a new tab)help.salesforce.com