A facilities contractor running maintenance across forty retail sites, or an engineering firm servicing HVAC and electrical plant for a dozen commercial clients, usually ends up running three separate records for the same piece of work. The field service management platform schedules the job and dispatches the engineer. A permit-to-work process, often still paper-based or sitting in a separate EHS tool, covers the isolation or hazardous task itself. A spreadsheet or client portal somewhere tracks whether the SLA response time was met. None of these three are built to talk to each other, and most FSM vendors haven't tried to make them.
That's not really a criticism of FSM platforms. They were built to solve scheduling and dispatch problems: routing the right engineer with the right skills to the right job, tracking parts and costs, closing the ticket. Permit-to-work and PPM compliance sit outside that remit. Meanwhile the vendors who do permit-to-work well were usually built for a single industrial site with one safety case and one duty holder structure, not a service business working across dozens of client premises with different local rules on every one.
When permits, PPM and SLA evidence live in separate systems
An engineer turns up to isolate an electrical panel ahead of a scheduled PPM visit. The permit needs accepting by whoever holds that authority on the client's premises, which might be a facilities manager, a site duty holder, or someone the engineer has never dealt with before. The PPM task itself was scheduled weeks earlier in the FSM system against an asset record that has no idea a permit is required. And the client's SLA dashboard is quietly running a clock that started the moment the job was dispatched, regardless of whether the permit was accepted on time or at all.
Where these three things aren't connected, someone reconciles them by hand, usually after the fact, usually when a client raises a query or an audit request lands. That reconciliation work doesn't scale well once you're running PPM across hundreds of assets a month.
What permit-to-work needs to cover across multiple client sites
Field service technicians working under the Electricity at Work Regulations, PUWER 1998, or LOLER 1998 are often doing exactly the kind of task permit-to-work exists to control: isolating a circuit, working at height to reach rooftop plant, lifting a replacement unit into position. The regulations themselves don't mandate a permit in every case, permit-to-work is a recognised control measure rather than a blanket legal requirement, but for higher-risk isolation and lifting work it's accepted practice for good reason.
The complication in field service is that each client site has its own local authorisation structure. There's no single asset hierarchy or duty holder the way there is on an offshore installation or a single industrial plant. We've written before about the practical difference between control of work, permit to work and CMMS, and that distinction matters even more where a service business is carrying permit obligations across dozens of unrelated premises rather than one site it knows inside out.
PPM scheduling needs to know a permit is coming
PPM scheduling inside most FSM platforms is driven by asset and frequency, a boiler due its six-monthly service, a fire damper due its annual drop test. Where a written scheme of examination applies, that scheduled date isn't a maintenance preference, it's a compliance obligation tied to a specific regime such as LOLER thorough examination or PSSR written scheme requirements for pressure systems.
If the PPM schedule has no visibility of the permit process, it has no way of flagging that this week's visit depends on an isolation being accepted on site first. Where the permit is delayed, refused, or needs a second attempt, the PPM date can slip without the scheduling system registering anything is wrong, and that's usually only discovered when someone asks for the examination certificate.
SLA evidence needs to show the work was done safely, not just logged
Many field service contracts now define SLA performance in terms of evidence as much as timing, not just that an engineer attended within the contracted window, but that the work was carried out under a properly accepted permit with isolation verified before anything was touched. If that evidence sits in a completion note in the FSM job record while the permit itself sits elsewhere, proving it for a client audit means pulling two separate records and hoping the timestamps agree.
What to ask a vendor before assuming this is covered
A few things are worth checking directly rather than taking on trust. Ask a vendor to show a single job where a PPM visit and an isolation permit are linked, not two separate screens you have to cross-reference manually. Ask whether a completed permit from eighteen months ago can be retrieved exactly as it stood at close-out, not regenerated from current data. Ask whether the SLA clock reflects permit acceptance time or only dispatch time, since those can be hours apart on a job requiring isolation. And ask how the system handles the same engineer working under different local authorisation structures on consecutive jobs at different clients that same day. If the answer involves exporting from one system and reconciling in another, that's useful to know before, not after, you've signed.
Our own work on auditable control of work software and on connecting permit, isolation and maintenance records covers a lot of this ground in more detail, built from implementing these workflows rather than researching them after the fact.
If you're mapping out where your current FSM, permit and compliance records sit before evaluating a change, that's usually the more useful starting point than comparing feature lists. Working out which system actually owns the permit record, which owns the PPM date, and which owns the SLA evidence tends to surface the gap faster than any vendor demo will.