A GPS canvas app engineers actually use, one tap to check in, live visibility for managers
A canvas app for engineers working on site: one tap to check in when you arrive, one to check out when you leave, and position captured automatically on the tap. Managers get a live view of who is where. Time on site is calculated rather than remembered and written down at the end of the week.
The most useful thing about this project is not in the app. It is that user testing killed the clever version. The design I set out to build used automatic geofencing, check in without touching anything. What shipped is a button an engineer presses, because that is the version they trusted and therefore the version they use.
Site attendance was reconstructed after the fact. Engineers recorded arrival and departure from memory, often days later, and managers had no view of the day as it happened, only a set of numbers arriving too late to act on.
Everything downstream inherits that lag. You cannot dispatch on position you do not have. You cannot answer "is anyone near this job" without ringing round. And time on site, reconstructed from memory at the end of a week, is a number nobody fully believes and nobody can check.
The app is deliberately small. An engineer working on a customer site, often one-handed, will not navigate a menu, so the entire primary interaction is a single button whose label tells you what will happen when you press it.
A canvas app on the engineer's phone reads the device GPS signal and writes a check-in record into Dataverse against the site and job. Managers read the same table live; the derived time-on-site value and the dispatcher both hang off it.
Keeping the check-in record as the single source of truth, rather than one store for attendance and another for dispatch, is what let the dispatcher reuse it later without any integration work at all.
The original design used geofencing: cross a boundary around the site, get checked in automatically. It is the better idea on paper. It removes a step, it cannot be forgotten, and it is the version that demos well.
User testing was unambiguous. Engineers did not trust it. Not because it was inaccurate, because they could not see that it had worked. An automatic check-in that happens silently gives you nothing to confirm, and the moment somebody suspects the system missed an arrival, they start keeping their own parallel record. At that point you have added work rather than removed it.
A manual tap has a worse theoretical experience and a far better real one: the engineer performs an action, sees it confirmed, and knows the record exists. It also handles the messy cases geofencing gets wrong: large sites, adjacent buildings, arriving before the job is due to start.
So the app ships with the button. Adoption beats elegance: an elegant feature nobody trusts has a real-world accuracy of zero, because it gets worked around. I would rather ship the version that gets used.
Site attendance is now recorded as it happens, by the person it happened to, with a position attached. Managers see the day while it is still possible to do something about it, and time on site is derived rather than recalled.
The wider payoff was unplanned. Because check-ins are captured live and stored as first-class records, they became the position signal the AI Job Dispatcher assigns on, so the small app that engineers actually adopted is what made the larger automation possible.
Building agents on the Power Platform, or trying to get one past a pilot? I am happy to talk it through.
Get in Touch →