Field Service: How to Bring In Service Partners

External service partners and subcontractors belong in your own processes in Salesforce Field Service. The goal is that the two worlds do not drift apart: dispatchers and technicians work the same way as far as possible, whether an internal or an external technician takes the job. Technically that usually means scheduling every partner technician as a resource of their own, giving them the same mobile app and separating the partner by a service territory of their own. In several of my projects that was exactly the goal.

This article is part 6 of the series. Licence prices for subcontractors are in part 1, how the scheduling engine decides is in part 3.

Internal and external technicians work the same way

Many manufacturers cover peaks, remote regions or certain trades with partners. If the partner is steered on the side, by email, phone and their own spreadsheet, two worlds appear. The dispatcher has two plans. The customer gets two kinds of service report. The partner’s spare parts and working time only arrive with the invoice, and the asset history has gaps.

When both worlds work the same way, that goes away. The dispatcher sees internal and external technicians in the same plan, the engine chooses by the same rules, and every job ends with the same documentation on the same asset. The partner gains too. They get jobs with all the information about the asset instead of calling back for every order, and they know earlier what is coming in the next days. That makes them easier to plan, for their own people too. The master data from part 2 then applies to partners too: skills, territories and absences.

Which models does Field Service offer?

According to Salesforce Help1 there are two ways to represent a partner:

	Each partner technician as a service resource	Only the partner as a capacity-based resource
Scheduling	Engine schedules each technician	Engine schedules against a capacity, the partner assigns people
Mobile app	Every technician uses it	Optional, often only the partner manager
Skills	Maintained per technician	Only for the partner as a whole
Effort	Higher, every technician needs a user	Lower
Same way of working as internal	Yes	Only partly

According to Salesforce Help2, a capacity-based resource can take a set amount of work per period, for example eight hours or five appointments a day. It does not support everything though, such as absences, optimization of a single resource or complex work with several appointments.

For the goal of the same way of working, the first model fits better. The second makes sense for partners who only step in now and then and steer their people themselves anyway.

What do partners need technically?

The steps are in Salesforce Help on contractor access3. In short:

• Account and contacts. The partner company is an account, its technicians and the partner manager are contacts.
• Community licence. Partners work as users of an Experience Cloud site, with Customer Community Plus or Partner Community, depending on what the company bought.
• Field Service permissions. The permission set licences Field Service Scheduling and Field Service Mobile, plus a permission set of its own with the object rights needed.
• Own profile and own mobile settings. That way the app can be configured differently for partners without changing the internal version.
• One service territory per partner company. The partner manager then sees only their own people and appointments. If they should dispatch themselves, the dispatch console can be added to the Experience Cloud site.

There are two kinds of licences. Partners who work regularly get licences per user. For seasonal or rare work there are licences per login, according to Salesforce up to 20 users per login bought. How to spread licences sensibly across all roles is covered in Salesforce licences: does everyone need a full licence?, and the Field Service roles in detail in Salesforce Field Service licences: who needs which?.

What does a partner job look like from start to finish?

Played through once, in the first model: equipment fails at a customer in a region without own technicians. The work order is created like any other, with work type, required skills and parts. The engine finds a technician with a matching skill in the partner’s territory and proposes them. The dispatcher reviews the proposal as in part 3 and releases it. The partner technician sees the appointment in their app, with asset, history and checklist. On site they record working time, parts used and measured values and get the customer’s signature. The service report comes from the same template as for internal technicians. What the standard can do there is covered in Service Documents: is Document Builder enough?.

For the customer, the job then looks exactly like one with an own technician. For the back office, everything sits on the same asset. And the partner invoice can be checked against the feedback from the app instead of a handwritten report.

Data access, invoicing and proof of skills stay separate

The same way of working does not mean the same rights. I would separate three things on purpose:

• Data access. A partner technician sees their appointments, the asset and the history they need for the job. Contract details, prices and other customers stay hidden. Sharing via territory and profile handles that. Also agree with data protection which customer data a partner may see, and put that into the contract with the partner.
• Invoicing. Internal jobs run through cost centres, partner jobs through an invoice. The feedback from the app, working time and parts used from part 4, is the basis for checking that invoice.
• Proof of skills. For your own technicians, HR maintains the skills. For partners it has to be clear who reports them and who checks them before the engine schedules the partner for a job.

First step: write down how a job reaches your most important partner

Take your most important partner and write down how a job reaches them today and how the feedback comes back. Every step that runs differently from internal technicians is a candidate for alignment. Start with one partner and one territory before connecting all of them. Mixed setups are fine: a large core partner works in the first model, a small partner for peaks in the second. What matters is that the decision is made deliberately per partner and documented. How the rollout then runs in waves is covered in the last 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 on contractor access (opens in a new tab)help.salesforce.com