# How to manage contractor scheduling in Field Service Lightning A contractor is capacity with skills, hours, and a territory. Lend them an employee login and you will either hide the wrong records or show them. **Published:** 2025-10-28 **Canonical:** https://synconai.com/contractor-scheduling-field-service **Author:** SynconAI Architecture Team ## In short Treat a contractor as capacity: skills, hours, and a territory they may work in. A borrowed employee login hides records they should not see, or blocks records they should. Work orders already carry preferences, required skills, and parts. Multilevel territories already describe where mobile workers can go. The product is Agentforce Field Service and Operations. ## Sources - **Agentforce Field Service and Operations** (retrieved 2026-10-10) https://help.salesforce.com/s/articleView?id=service.fs_overview.htm&type=5 > Schedule one-time or recurring work orders for customers, and add details about worker preferences, required skills, and parts. - **Agentforce Field Service and Operations** (retrieved 2026-10-10) https://help.salesforce.com/s/articleView?id=service.fs_overview.htm&type=5 > Set up multilevel service territories that represent the regions where mobile workers can provide services. ## What to take away - Give each contractor their own user. A shared login cannot tell their hours from an employee’s, or their records from the whole organisation. - Their territory membership is the region they may be sent into. Their hours are the shift they actually work. - Work orders carry preferences, required skills, and parts. The contractor should see the work order for the job, not the rest of the book. - Multilevel territories are the documented model. Put the contractor on the patch they cover, not on the sales region because it was easy. ## The guide 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. ::: warn A borrowed login makes the attendance record a lie. The name on the appointment is whoever owns the user, not whoever stood in front of the machine. The next audit, the next warranty argument, and the next "who was on site" question will all use that name. Fix the user before you defend the visit. ::: ## 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. ::: note Run the test on the contractor's user, on their phone, against a job they should see and a job they should not. An administrator's session cannot fail this test, which is why so many designs pass it in a meeting and fail in the van. ::: ## 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](/skill-based-routing-field-service). 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 | Fact | Put it here | Leave it off the contractor | | --- | --- | --- | | Who attended | Their own user, on the appointment | A supervisor login shared for the week | | When they exist | The hours in the contract | A copied employee roster | | Where they may go | The child territory for the patch they cover | The parent, because it was faster to load | | What they may do | The trade or ticket on their user, required on the work order | A skill called contractor | | What they may open | Assigned work orders in their territories | The country queue, other regions, the commercial file | | What the van should carry | Parts on the work order | A phone call from the kerb | 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. ## Questions ### Can contractors share one Salesforce login? They should not. A shared login mixes their hours, their territories, and their right to see records with whoever last used the password. The appointment then records the owner of the login as the person who attended, which is a false record for the next audit. Give each contractor a user, then limit what that user can open to assigned work in territories they belong to. The scheduling optimizer can only match skill, travel, and location against an identity you actually stored. Two people on one user are one person to the scheduler. ### Where do contractor skills and parts go? On the work order. Salesforce documents work orders with worker preferences, required skills, and parts. The contractor skills sit on their user, so the job and the person can be matched. Contractor is not itself a skill. The required skill is the trade, the plant, or the ticket. Parts stay on the work order so they are not discovered by a phone call from the kerb; if the contractor supplies their own consumables, the work order should say that too. ### How should contractor territories be set up? Use multilevel service territories for the regions where they can actually provide services. Put them on the child patch they cover. Do not leave them on a parent region because the sales map was already drawn that way. Parent membership can make them eligible wherever the parent reaches, which you should test rather than assume. When the agreement ends, remove the membership and the hours the same day. Old membership is how last year's contractor keeps receiving this year's work. ### What hours should a contractor have? The hours they work. If the contract is three days, storing a five-day employee shift will offer them work on days they are not there. The scheduler is following the hours you gave it, and the customer will get a window for a van that does not exist that day. Night rosters and short shutdown crews are hours too, not a note on the account. End the hours when the engagement ends, and check that offers actually stop. ### What is the product name behind Field Service Lightning? Agentforce Field Service and Operations, formerly Field Service. Field Service Lightning is the older search phrase. The help page still says Field Service in some places, which is Salesforce's own wording during the rename. Contractor design does not depend on which of those labels is on the screen. It depends on a user of their own, hours that match the contract, and a territory that matches the patch. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Field Service (https://synconai.com/salesforce-field-service).