← All articles

Part 4 of 7Series Salesforce Field Service for manufacturers

Field Service Spare Parts: ERP or Salesforce?

The ERP owns spare parts stock in field service, including the stock in the service van. In my projects it always did, and there were relatively few problems with that. Salesforce Field Service still needs a copy of the stock, so dispatchers and technicians can see which part is where, and it reports back which parts were used. Where problems came up, the split of tasks was not the cause. Data maintenance quality was.

This article is part 4 of the series. In part 2, missing spare parts were one of the reasons for failed visits. In part 3, “part not in the van” was a typical reason for a dispatcher to change the scheduling proposal. This part is about how spare parts come together in Field Service and the ERP.

The ERP owns the stock

In the ERP, a spare part is more than a quantity at a place. It has a value on the balance sheet, a purchasing process, minimum stock levels, suppliers and transfers between warehouses. Every withdrawal is a posting that reaches accounting. The ERP is built for this, and the processes there have usually run for years.

Field Service can hold quantities per location and log movements. It does not do valuation, purchasing or accounting, and it should not. Whoever wants to run stock in Salesforce rebuilds part of the ERP and has to reconcile both worlds forever. I have not seen a client do that, and I would not advise anyone to.

What does Field Service need to know about spare parts?

Field Service needs parts for two reasons: to prepare a visit and to document it afterwards. According to Salesforce Help1 there is a set of objects for that:

  • Locations are warehouses and vehicles. A service van is a mobile location with stock, as described in part 2.
  • Product items are the stock of one part at one location, such as “twelve seals in technician A’s van”.
  • Products required are the parts a work order needs. When they are recorded, the back office knows before the visit what has to go into the van.
  • Products consumed are the parts the technician actually used. According to Salesforce Help2, the product item quantity goes down automatically.
  • Product requests are part requests, for example when van stock runs low or a job needs a specific part. According to Salesforce Help3 they can be linked to work orders and have a van as their destination.
  • Product transfers and return orders cover transfers and returns.

Not every company needs all of them. If the ERP already handles part requests and transfers well, Salesforce often only needs the stock for display, the required parts on the work order and the consumption. Every additional object is another interface to maintain.

How does data flow between the ERP and Field Service?

The split follows a simple rule: the ERP delivers master data and stock, Salesforce delivers what happened on site.

Information Direction Timing
Material master (parts, numbers, descriptions) ERP to Salesforce on change
Stock per warehouse and van ERP to Salesforce regularly, at least daily
Consumed parts on the work order Salesforce to ERP after the visit is completed
Part requests from technicians Salesforce to ERP immediately, becomes a transfer or purchase order there
Returns depends on the process with goods receipt in the ERP

Decide early how current stock in Salesforce needs to be. For planning the next day, a nightly sync is often enough. Anyone who reschedules on the day of service needs shorter intervals. A B2B store faces the same question with a different consumer, see stock in the B2B store. Then decide what happens offline. The mobile app works without a network. For the technician to see their van stock there, it has to sit in Salesforce as a copy. A pure live lookup from the ERP does not work in the basement of a factory hall. Which data the app keeps offline is covered in Field Service mobile offline.

A third question is volume. Every part at every location is its own record. 40 vans with 300 parts each are already 12,000 product items, plus the warehouses. That is no problem for Salesforce, but every record has to be synced and ends up offline on the technician’s device. So I would only bring the locations into Salesforce that matter for field service: the vans and the warehouses that restock them. The rest of the company’s stock stays in the ERP, and the back office looks it up there when needed.

How to settle such interfaces and the question of which system leads is described on the page Salesforce integration.

The problems come from data maintenance

This is what I would work on before go-live:

  • Material numbers: a part that exists twice in the ERP, or with an outdated number, also lands twice in Salesforce. The technician then books against the wrong one.
  • Unbooked withdrawals: if a technician takes a part from the warehouse without a posting, the van stock no longer matches. Field Service then shows a part that is not there.
  • Parts without a link to the equipment: without a record of which part fits which machine, nobody can say in advance what a visit needs. The asset hierarchy from part 2 helps here.
  • Consumption only on paper: if the technician records consumption in the evening, or not at all in the app, it reaches the ERP late or wrong. The new forms and voice input described in Field Service Mobile: guided flows and voice can make this easier.

None of these problems is solved by software. Each needs an owner who maintains the data, and a process that makes wrong postings visible. A regular stock count of individual vans is a simple first step.

Have three technicians count their van

Check how accurate van stock in the ERP is today.

If it matches, decide which of the objects above you need, and start with stock, required parts and consumption. How maintenance contracts and committed response times reach scheduling is covered in the next part of the series.

Sources3
  1. 1Salesforce Help (opens in a new tab)help.salesforce.com
  2. 2Salesforce Help (opens in a new tab)help.salesforce.com
  3. 3Salesforce Help (opens in a new tab)help.salesforce.com

Frequently asked questions

Should Salesforce Field Service or the ERP own spare parts stock?

The ERP. It values the stock, runs purchasing and transfers and is connected to accounting. Field Service holds a copy for scheduling and technicians and reports consumption back.

How does Field Service represent the stock in a service van?

The van is a mobile location. The stock per part is a product item with the quantity at that location. When the technician records consumption on the work order, the quantity goes down automatically.

What is the difference between products required and products consumed?

Products required are the parts a work order needs and help with preparation. Products consumed are the parts actually used, and they reduce the stock.

Which data flows between the ERP and Field Service?

From the ERP to Salesforce: material master and stock per location. From Salesforce to the ERP: consumption from work orders and part requests from technicians, which become transfers or purchase orders there.

Related serviceArchitecture & solution design →

Contact

Does Field Service pay off for your technicians?

Whether scheduling and route optimisation pay off depends on a few numbers. With them I can give you a first assessment in 30 minutes.

What to bring

  • The typical job duration: closer to one hour or to several days per job
  • Travel time to the customer and how many jobs a technician completes per day
  • How you plan today, with how many dispatchers and how much effort per week

What we clarify

  • Whether your jobs benefit from Field Service or a leaner setup is enough
  • Which KPIs scheduling and route optimisation can improve
  • Which master data and interfaces, for example to the ERP, have to be in place first
Book a call (opens Microsoft Bookings in a new tab)

Pick a slot in my calendar via Microsoft Bookings. Prefer to write? Use the form and I’ll get back to you.

Rather talk right away? +49 221 98656758

Send a message

Your details are only used to answer your request. More in the privacy policy.