ChatGPT
Claude
Google AI
Copilot
A scanner beeped in the warehouse and the dispatch board gained a job. The status said received. A planner treated it as a technician event and offered it to the nearest van. The customer had posted the unit. Nobody needed to attend. The van went anyway, because a work-order status had been taught to mean "the parcel is here," and the board cannot tell a parcel from a visit.
People still search for RMA in FSL. FSL means Field Service Lightning. The hub they land in is described like this: "Agentforce Field Service and Operations (formerly known as Field Service) gives you a powerful, highly customizable, mobile-friendly field service hub in Salesforce."
That hub schedules work. "Schedule one-time or recurring work orders for customers, and add details about worker preferences, required skills, and parts." A work order is a visit, or a defined piece of work, for a customer. A return merchandise authorisation is a decision about goods: send it back, receive it, credit it, replace it. Those are different lifecycles. Forcing both through work-order status makes every report lie.
Two paths
Give the return its own path. The states are about the goods. Requested. Approved. In transit. Received. Closed, with whatever outcome you actually offer: credit, replace, or repair on the bench. None of those words should be a value in the work-order status list. The moment "parcel received" is a work-order status, dispatchers start treating a warehouse scan as if it were a technician event, and technicians inherit a queue of objects that are not jobs.
The lie spreads into the numbers. Open work orders include cartons. First-time fix, if you track it, gets applied to a parcel that arrived intact. Utilisation gets a visit that never happened, or a gap where a fake visit was cancelled at the kerb. The scheduling optimizer then accounts for skill, travel time, and location against a job that should not have been on the board. The offer is coherent. The record was not a job.
This page does not name a separate Salesforce object for that return path, because the help page we are using does not name one. Build the path so its state is obvious and is not the work order. If you already have a returns process outside Field Service, leave it there and link it. Do not migrate it into appointment status to make one screen feel complete. Completeness is how the parcel and the visit get welded together.
Parts are not the carton
Parts stay parts. The part you expect to remove or replace can sit on the work order when there is a visit. The part sitting in a carton at the dock is the return. Same physical thing, at different moments, different records. Updating the work order because a scanner beeped is how the two get welded together.
A replacement you are sending out is also not automatically a visit. If the customer fits it, you have logistics. If a person must attend to fit it, you have a work order, with the required skill and the part on it, created when that decision is made. Do not create the work order when the return is requested, "so it is ready." Ready means a ghost appointment. Someone will fill it.
The customer on the work order, when a visit exists, is the customer. You do not need a second, vaguer place to store "where the goods lived." The return can point at the asset and the account. The work order points at the same asset when you attend. Two pointers are fine. One status is not.
When a person has to go
Some returns never need a technician. The customer posts the unit. Your bench or your vendor handles it. Creating a work order at the start of that story puts a fake appointment on the board, and someone will try to schedule it. The optimizer will try too, if the record looks like other work: a duration, a territory, a skill left over from a template that did not apply.
Create the work order when a person must attend the customer site, or when the bench work is truly something you schedule as work. Then fill in what the help page already expects: preferences, required skills, and parts. Site induction, the skill to remove the unit, the replacement part if you are swapping on site. A duration from similar attended swaps, not an hour because the field was mandatory. A short duration on a swap will stack the rest of that person's day into a fiction, the same way it does on any other work type.
If the return is approved but the visit is not agreed, you have a return and no appointment. That is a valid state. It should look unfinished on the return, and absent from the dispatch board. Managers who want one number for "open returns plus open jobs" can add it in a sentence. They should not get it by storing both in the same status, because the sentence can be questioned and the status will be scheduled.
Status hygiene
Read your work-order status list with a dispatcher. Cross out every value that describes a parcel, a credit, a pick, or a warehouse. Those values move to the return path. What remains should be things a dispatcher understands: new, scheduled, in progress, completed, cannot complete. If you need more visit states, add visit states. Do not add logistics states in the same picklist because there was a spare row.
Then read a month of records that used the crossed-out values. Each one is either a visit that was mislabelled or a parcel that was pretending. Move the parcels. Relabel the visits. Leaving them "so history is unchanged" keeps the lie in every report that still filters on those values. History can keep the old word on the return. It should not keep scheduling meaning on the work order.
Report them apart. Open returns are not open work orders. A manager who adds the two numbers will panic, or celebrate, for no operational reason. First-time fix applies to the visit. It does not apply to a parcel that arrived intact. Travel time applies to a person who went. It does not apply to a courier. If a dashboard adds them, split the dashboard. The argument you want is about visits, and it cannot be had while cartons are in the total.
| Moment | Return path | Work order |
|---|---|---|
| Customer asks to send the unit back | Requested, then approved or refused | None |
| Unit is on the way, or on the dock | In transit, then received | None, unless a person must attend |
| Bench or vendor handles it | Closed with the outcome you offer | None, unless that bench work is truly scheduled work |
| A person must go to site | Stays on its own path | Create one. Skills, parts, preferences, a real duration |
| Goods were received and a visit is later required | Keep the return. Point the visit at it | New work order. Do not reuse the return's status list |
When the visit comes later
When a received unit later needs a site visit, open a work order and point it at the return. Copy the skills and parts you now know. Do not flip the return into a scheduled appointment and hope the status still means what it meant last week. Last week it meant the carton arrived. This week it would mean a technician is due. Anyone who saved a report filter on the old meaning will now dispatch, or will stop trusting the report. Both are failures of a reused word.
Start that work order from the template for the visit, not from the return's form. The template knows the tasks, the skill, and the usual parts. The return knows the goods. Mixing the forms is how a warehouse instruction ends up as a step the technician is told to perform at the kitchen table. The standard for what a template must contain is in custom work order templates. Use it for the visit. Leave the return off it.
Appointment Assistant, if you remind the customer, waits until that visit has a window you will keep. A message sent when the return is approved, talking about a technician, invents a visit you have not decided to perform. Silence is accurate until a person is actually going.
Credit, replace, and repair are outcomes of the return, decided by a person who owns that policy. They are not work-order statuses, and they are not a duration. A credit does not need a skill or a territory. A replacement the customer fits does not need one either. Only the outcome that puts a person on site becomes a work order, and only at the moment you decide they are going. If the policy is unclear, the unclear part is commercial. Do not hide it in a picklist the dispatcher has to ignore.
Keep the link in one direction you can explain. The visit points at the return. The return does not become the visit. A report of visits can show the related return without listing the return as work. A report of returns can show whether a visit happened without counting the return as an appointment. If either report only works when the status values are shared, the report is the thing to rebuild. The status list is already doing too much. Walk one returned unit through every state with the warehouse and with a dispatcher in the room. Each person should be able to say which record they update, and which board they do not touch. If both reach for the work order, the paths are not separate yet. Repeat the walk with a unit that never needs a visit, and with a unit that does. Both stories should be obvious on the records without a narrator.
Agentforce Field Service and Operations will schedule the work orders you create. Field Service Lightning is only the name in the search. Create a work order when someone must attend. Keep every parcel word off that record. The scanner can beep. It should not move a van.
