ChatGPT
Claude
Google AI
Copilot
The phone rang all morning. Each ring was a work order, and each work order was a reading that had twitched. Two technicians were dispatched to the same machine for the same fault. A third was sent to a serial number the company does not service. The sensor was doing what sensors do. The integration had no rule in front of it, so every message became a job.
People still search for Salesforce Field Service Lightning. The help page names the product in full: "Agentforce Field Service and Operations (formerly known as Field Service) gives you a powerful, highly customizable, mobile-friendly field service hub in Salesforce." IoT does not change that hub. A reading is useful when it becomes the right work order, and noise when it becomes all of them.
The work order is the documented object. "Schedule one-time or recurring work orders for customers, and add details about worker preferences, required skills, and parts." Integration means a reading that has earned a work order arrives with those details filled. It does not mean a technician is paged because a value twitched.
A threshold a person set
Pick the condition in words before you pick a pipe. Temperature above a number you can defend, for longer than a wobble. Vibration past a limit more than once in a shift. A fault code your maintainers already treat as "attend this week," not "attend in ten minutes." Write the number down. If you cannot write it, you are not ready to connect anything.
The number has to come from people who have attended the failure, not from the default that shipped with the feed. A default is usually sensitive, because a missed event looks worse in a demo than a noisy one. Your depot will live with the noise. Ask the maintainers what they already ignore, and what they wish they had heard an hour earlier. Those two lists are the threshold. Everything else is a reading you store or discard, not a job.
A person owns the threshold. When it is wrong, that person changes it. Put their name on the rule. An automatic feed with no owner will open work orders forever, and the organisation will blame the sensor. The sensor did not decide that a one-degree move was a visit. Somebody's unset default did, and nobody is allowed to touch it.
Review the rule on a cadence that matches how often the plant lies to you. A new machine family, a seasonal load, a firmware change on the asset: each can make a true threshold false. The owner reads a week of created work orders and asks which ones a dispatcher would have opened without the feed. The ones they would not have opened are the rule being too eager. Tighten it. Do not add another queue to hide them.
Suppress the repeat
The same asset, the same fault, still open, should not create a second work order and a second page. Update the open one, or wait. Two technicians for one fault is how the design announces that nobody designed it.
Say what "the same fault" means before the feed is live. The same code on the same serial number, while a work order is not completed. A related code that your maintainers treat as the same failure. Write that down too. If you leave it to the integration to decide, it will decide that every message is new, because that is the simplest code to write.
Closing the work order has to be real. A technician who cannot complete, and a status that still counts as open, should keep the suppression in force. A status that means "parcel received" or "customer notified" is not a reason to open a twin job. The open work order is the claim on that fault. A new reading is a comment on it, or nothing.
Page a person only for the class of threshold you marked as immediate. Everything else waits for the normal scheduling run. The point of the integration is fewer surprise failures, not a phone that never stops. Immediate means safety, or a stoppage you have contracted to attend now. "The chart looks bad" is not immediate. It can wait for the planner who already builds the day.
The asset under contract
The reading has to point at an asset you service. Serial number, install location, customer: whatever you already trust. If the match fails, do not create a work order for "unknown asset" and hope a dispatcher will sort the pile. Hold the reading for a person. A wrong asset match sends a skilled person to the wrong machine, which is worse than no alert.
The match fails in ordinary ways. A serial number with a space. A replacement unit that inherited the old unit's place in the building and not its identity. A sensor fitted to a machine you sold and no longer cover. A test device that was never removed from the feed. Each of these will look like a confident match or a confident job if you let the feed create first and ask later. Hold first. Create when a person, or a rule a person still owns, can say this is our asset.
Contract matters. If the warranty or the service agreement does not cover that asset, the correct result might be a quote, or nothing. A work order implies you have decided to attend. Do not let a sensor make that commercial decision because the integration was easy. Commercial coverage is a fact you already have on the asset or the account. Read it. A covered asset can become a work order. An uncovered one becomes a task for the person who sells the work, and it stays off the dispatch board.
What the work order must contain
When the rule fires, the work order should already say the required skill, the parts you expect to use, and any customer preference that changes the visit. A bare work order titled with a fault code forces the dispatcher to reconstruct the job. That reconstruction is the delay the sensor was supposed to remove.
The fault code is not a skill. Map the codes you care about to the skill that fault actually needs, the same way you would on a job a customer phoned in. If three codes all need the same ticket and the same kit, they can share a work type. If one code needs a different trade, it needs a different work type. Do not send every code to "technician" because the mapping spreadsheet was unfinished.
Set a duration from similar attended jobs, not from zero, and not from an hour because the field was mandatory. The scheduling optimizer can only be as honest as that duration. A sensor-created job with a fake hour will be slotted into a day that then slips. The optimizer accounts for skill, travel time, and location as well. A job with a blank skill and a fake hour will be offered to whoever is closest. You have automated the wrong offer.
Preferences belong on the work order even when a machine opened it. Access hours, induction, a contact who must be on site. A feed does not know them. The asset and the account do. Copy them when the work order is created. A perfectly timed alert that arrives when the site is shut, with no note to say so, still wastes the trip.
How a template carries skills, parts, tasks, and a duration that is not a guess is set out in custom work order templates. Point the feed at that template for the fault. Do not point it at a blank work order and hope the dispatcher fills the gap faster than the phone used to ring.
What a reading is allowed to do
| Reading | Asset and contract | Open job for the same fault | What happens |
|---|---|---|---|
| Inside the threshold | Either | Either | Nothing. Store it if you must. Do not create a work order |
| Past the threshold | Match fails, or not your contract | Either | Hold for a person. No dispatch |
| Past the threshold | Your asset, covered | Already open | Update the open work order. Do not page a second technician |
| Past the threshold, not immediate | Your asset, covered | None open | Create the work order from the template, and let ordinary scheduling take it |
| Past the threshold, and you classed it immediate | Your asset, covered | None open | Create the work order, then page. Skill, parts, and duration are already on it |
If you cannot fill this table for a feed you are about to switch on, you are not integrating. You are forwarding mail into the dispatch queue. Switch it on only for the rows you can explain, for one family of assets, and read every work order it creates for a fortnight.
A fortnight on one family
Choose the asset family whose failures you already understand. Write the thresholds, the owner, the same-fault rule, and the template. Connect that family only. Count three things. Work orders a person would not have opened. Second work orders for a fault that was already open. Jobs whose asset or contract was wrong.
Those three counts are the design. If the first is high, the threshold is eager. If the second is not zero, suppression is missing. If the third is not zero, the match is not safe and the feed should hold, not create. Fix the rule. Then add the next family. A national switch-on, with a default of create-on-message, will fail in every depot at once, and the depots will be right to switch it off.
Keep the feed out of the scheduling optimizer's inputs except through the work order. A reading is not a skill, a territory, or a duration. Once it has created a proper work order, the optimizer can account for skill, travel time, and location the way it does for a job a person raised. Until then, the reading stays off the board. A live pin from a sensor is not a reason to drag a technician across a territory the membership does not allow.
Do not page anyone for a blip. Do not name a platform in the design until you have bought one, and do not let the purchase rewrite the table. The hub is still Agentforce Field Service and Operations. Field Service Lightning is only the name on the search. The work order is still the job. The reading earns one when a person-sized rule says so, and not before.
