Why engineers get their own interface
BMS could have made the desktop Service screens responsive and left it there. Instead there is a separate interface, with its own routes, its own screens and its own vocabulary. That is a deliberate choice, and the reason is not screen size.
The engineer's job is not the desk's job
Open the desktop job screen and you get the customer's problem: the job, its activities, its history, its financials, everything anyone might need. That is right for a service desk deciding what to do about a fault.
An engineer does not need any of that. They need to know which machine, what is wrong with it, and have I got the parts — while standing up, holding a phone, possibly in a plant room with one bar of signal.
Those are not the same screen made narrower. They are different questions, and a responsive layout would have answered the desk's question badly on a small screen rather than answering the engineer's well.
It works in visits, not jobs
Every screen in the mobile app is one activity. Cards say RJ-P036593 (visit 2); the URL is a job activity; the list is "your visits".
The desk thinks in jobs because a job is the customer's problem, and the customer is who they answer to. An engineer is dispatched to a visit — a specific attempt, on a specific day, by them. Making the activity the unit means nothing on screen is about attempts other people made, except where it genuinely helps: the asset's Job History, which is exactly the "what did we try last time" question.
Required items become used items
Before the visit, the screen shows what is needed and whether it is allocated. After it, the same section shows what was consumed.
That is the app's whole shape in miniature: a plan on the way out, a record on the way back. The engineer is the only person who can turn one into the other, and the app asks them for exactly that — the parts, the labour, the resolution, the signature — and nothing else.
Why it is invisible to everyone else
Access needs the mobile role and a linked engineer record, and an account without both sees an empty list rather than an error.
That is a reasonable trade that catches people out. Making it an error would mean explaining a permissions concept to the one group of users least able to act on it. Showing an empty list is right for the engineer with genuinely no work today, and merely confusing for the administrator who should not have been there — which is the better way round, though it does mean the app looks broken the first time an office user opens it.