← All work

Power Apps · Copilot Studio · Dataverse

Field Safety Assistant

Crews need procedures on site and incidents written up accurately, often with no signal.


The problem

A construction or trades business carries a safety documentation obligation that lives in binders and PDFs, and a workforce that is on sites, in vehicles, and frequently without reliable signal. Two things go wrong. Crews cannot check a procedure at the moment they need it, so they rely on memory. And incidents get written up hours later from recollection, which is when detail and accuracy are lost.

Turnover makes both worse. The same induction questions recur permanently, and the answers are given informally by whoever is nearest.

Why two tools rather than one

Looking up a procedure is a question, and a grounded agent handles it well. Recording an incident is structured data capture with photographs, a timestamp, and a location, often with no connectivity. That calls for a mobile app with offline storage. Trying to capture an incident through chat on a bad connection produces exactly the outcome the system exists to prevent.

So: an agent over the safety corpus for questions, a Power App for capture, and one Dataverse model underneath both.

Architecture

Field Safety Assistant architectureTwo tools over one data model. A Power App captures incidents offline and caches procedures locally. A Copilot Studio agent answers procedural questions with citations but requires connectivity. Both read and write the same Dataverse tables.On sitePower App — captureIncident reports with photographs, timestamp, locationCached procedures for offline readingLocal write queue, syncs on reconnectBuilt for gloved hands and bright sunlarge targets, high contrast, few tapsCopilot Studio agent — questionsGrounded on the controlled safety corpusCites the controlled document versionHandles recurring induction questionsRequires connectivitywhich is why capture is not built this wayConnectivity boundary — capture must work offlineThe capability that must never fail is the one built for no signal.Dataverse — one data modelIncidents · Procedures · Sites · CrewSupervisors see one picture rather than two systemsAccess rules and retention agreed before rolloutSuperseded procedures leave the corpus when superseded — document control is a compliance requirement here, not hygiene.
Capture must work offline, so it is not built as a conversation

The Power App holds a local cache of procedures and queues incident records while offline. The agent answers procedural questions with citations to the controlled document. Both read and write the same Dataverse tables, so a supervisor sees one picture.

The constraint that drives the design

Offline is the default assumption, not the edge case.

Everything a crew member needs to do must work with no connection and reconcile later. That means the app holds cached content and a local write queue, sync happens on reconnect, and conflicts resolve without losing a submission. An incident report that fails to send and disappears is worse than a paper form.

The agent, by contrast, needs connectivity. That asymmetry is deliberate: the capability that must never fail is the one built to work offline.

Delivery considerations

Document control is a compliance requirement here. The agent must cite the controlled version, and superseded procedures must leave the corpus when they are superseded.

Photographs dominate storage. Image handling and retention need sizing before rollout rather than after.

Field usability outranks feature count. Gloved hands, bright sun, cracked screens. Large targets, high contrast, and few taps.

Incident data is sensitive. Access rules and retention need agreeing with the client up front, because this is one of the few datasets that may end up in a legal process.