How to manage contractor scheduling in Field Service Lightning

A contractor arrives, opens the laptop, and is looking at another customer's open jobs. The login was a supervisor's. It was lent for the week because raising a user felt slow. By Thursday the password is on a group chat. The appointment record says the supervisor attended. The contractor did. An audit will notice, and it will not be interested in how convenient the shortcut was.

People still search for Field Service Lightning. The product on the help page is Agentforce Field Service and Operations, formerly Field Service. Contractor scheduling uses two things that page already names.

Salesforce says you can "Schedule one-time or recurring work orders for customers, and add details about worker preferences, required skills, and parts." It also says: "Set up multilevel service territories that represent the regions where mobile workers can provide services." A contractor is a mobile worker with a narrower week and a narrower right to see records. Design for that. Do not disguise them as an employee.

#Capacity, not a borrowed login

A contractor brings hours, skills, and a limit on what they may open. An employee login brings someone else's sharing, someone else's territories, and a password that gets passed around the crew. When that login is too wide, the contractor sees customers they do not work for. When a well-meaning admin then locks it down ad hoc, the contractor cannot see the work order they were sent to do.

Both failures come from the same shortcut. The wide login is a privacy problem and a commercial one. The contractor can read sites, assets, and prices that were never part of the engagement. The locked-down login is an operational problem. The person is on site, the job is on the board, and the phone cannot show it. Dispatch then reads the job out over the radio. The record of what they were told is gone. The next visit starts from memory.

Give them their own user. Put on it the skills they hold and the hours they work. If they work Tuesday to Thursday, those are the hours. Copying an employee's Monday-to-Friday shift will make the scheduler offer them Monday work. Someone will then call the product broken. The product offered a person it was told was available. The hours were the lie.

A shared login cannot tell those hours apart, and it cannot tell their jobs apart. Two contractors on one user means one set of skills, one territory list, and one stream of appointments. The optimizer accounts for worker skill level, travel time, and location against that single identity. It cannot prefer the person who actually holds the ticket if both people are the same user. You have deleted the fact the scheduler needs.

#What they are allowed to see

The work order is the record they need: the customer, the preferences, the required skills, and the parts. They do not need the organisation's other open jobs, other regions, or the commercial file sitting on the account because nobody split the layout.

Write the rule in plain language, and write it before the profile is cloned from an employee. A contractor opens work orders assigned to them, in territories they belong to. They do not open the unassigned queue for the country. They do not browse assets they are not attending. If a supervisor wants them to see tomorrow's job tonight, that is an assignment, not a reason to widen sharing to the whole service territory parent.

The layout matters as much as the sharing rule. A work order page that shows every related list an internal dispatcher uses will show the contractor the quote, the margin, and the other sites on the account. Remove those from the layout they get. The job can still carry preferences, required skills, and parts. Those are the details Salesforce documents on the work order, and they are the details required to do the visit. The rest is internal.

Check it with a real login, not with a system administrator. Administrators can see everything, so their test proves nothing. Log in as the contractor, on the device they use, and try to open a job in the next patch. If it opens, the design is wrong. Then try to open the job they were actually assigned, with the device offline if that is how they work. If it does not open, the design is also wrong. The Field Service mobile app is offline-first. A permission that only works on the office network is a permission they do not have on site.

#Hours are the contract, not the roster

Store the days they are engaged. A three-day contract stored as a five-day shift creates two days of appointments nobody will attend. The customers get a window. The van does not come. That looks like a no-show, and it is an hours record.

Night work, a summer pattern, a shutdown crew that exists for a fortnight: each of those is a set of hours, not a note on the account. If the hours say they are free, the optimizer may use them. Travel and skill will look fine. The person is not in the state.

When the contract ends, end the hours and the membership the same day. Leaving the user "in case they come back" leaves a person the scheduler can still offer. Deactivate, or set hours that contain no shift. A user who can log in and a resource who can be scheduled are related, and they are not the same switch. Check both.

Relievers borrowed from another contractor for a day need that day's hours, on their own user, in the territory for that day. Do not stretch their home patch to cover the gap. A one-day membership that is removed afterwards is clearer than a permanent membership everyone promises to remember.

#Territories and the work itself

Multilevel territories are how you say where this person may provide service. The parent might be a state. The child should be the patch the contractor actually covers. Membership of the parent, with no thought, can mean they are eligible wherever the parent reaches. Read the membership before you assume. The point of the level is the region they may enter, not a tidy org chart.

Put them on the child. Then ask a dispatcher a specific question: could this contractor be offered that other patch? If the answer is yes and the contract says no, the membership is wrong, whatever the diagram claimed. The test is the same one you would run for an employee. Contractors fail it more often because they were loaded in a hurry, onto whatever territory already existed for the sales region.

Skills stay specific. "Contractor" is not a skill. The required skill on the work order is the trade, the plant, or the ticket. A skill called contractor matches every contractor and none of the employees, or the other way around, and it still does not say who may isolate the plant. How to decide which skills earn a requirement is set out in skill-based routing. Use that list. Do not invent a parallel list because the worker is external.

Parts stay on the work order too, so they are not ringing the depot from the kerb to ask what was supposed to be in the van. If the contractor supplies their own consumables, say so on the work order. If your store supplies a crate, the crate is a part the job must show before anyone is scheduled. A contractor who arrives without it has been scheduled onto a guess.

#Their name on the appointment

Schedule them as themselves. Their name on the appointment, their hours, their territory. When the job is done, the record of who attended is theirs. A borrowed login makes that record a lie, and the next audit will notice.

This matters when the work is subcontracted under your brand. The customer sees your name. You still need to know which legal person was on site, which ticket they held, and which hours they were engaged for. The user is that record. A whiteboard in the depot is not. If the whiteboard and the appointment disagree, the scheduling optimizer will follow the user. The whiteboard will not update it.

#What to set, and what to leave alone

Read the right-hand column with the person who owns the contractor agreement. If any of those are still true in the org, the scheduler is being asked to treat an outsider as an employee, and then being blamed when it does.

#Check a real week

Pick one contractor who worked last week. Compare three lists. The days the contract said they would work. The hours stored on the user. The appointments they were offered. Any appointment on a day they were not engaged is an hours error. Any appointment outside the patch is a membership error. Any job they could open and should not have is a sharing error. Fix the record that failed. Do not write a reminder to be more careful.

Then log in as them and repeat the open-and-do-not-open test. Include a job assigned for tomorrow, so you know the briefing arrives before the day, and a job in the next patch, so you know it does not. Do it on the device they carry. An office browser on an administrator's desk is how the last design was signed off.

When a new contractor starts, the same three facts are the whole setup. User, hours, child territory, skills they hold. Work orders they are assigned, with preferences, required skills, and parts already on the job. Nothing else. The employee template is the wrong starting point, because it carries a week, a region, and a set of records this person was never meant to see. Copying it and then deleting feels faster. It leaves the deletion for later, and later is when they are already in the van.