Offline Inspections on an E3 Budget
Metro Water's 38 field inspectors record chlorine residuals, valve status and photo evidence on paper forms dropped at a depot each Friday. A business analyst in operations proposes replacing this with Power Apps. Constraints: inspectors work in basements and rural pump stations with no signal for two to four hours at a stretch; volume is roughly 2,100 inspections per month; devices are shared three-year-old Android tablets; the organization holds Microsoft 365 E3, so there is no Power Apps premium entitlement and no Dataverse; the center of excellence's data loss prevention policy blocks custom connectors and restricts storage to SharePoint. IT will not fund premium licenses this fiscal year but will permit a governed SharePoint list. A vendor demonstration of a model-driven app with offline sync impressed the analyst, who now wants to replicate it. Supervisors need same-day visibility of results and exceptions.
1. Evaluate the platform options against the constraints and recommend one, with reasoning.
Read the worked answer
The model-driven offline design the analyst saw in the demo cannot be delivered under the current entitlement. Model-driven apps and the platform's built-in mobile offline capability depend on Dataverse, which requires premium licensing. Choosing it would produce a prototype that cannot go live - a common and expensive failure pattern.
Under E3, the available path is a canvas app using standard connectors, principally SharePoint. That is a real capability, but it has two hard limits that must be designed around: there is no supported offline mode for canvas apps in this configuration, and SharePoint list behaviour constrains performance and attachment handling.
Options to weigh:
- Canvas app, online-only, synced at depots. Cheapest and most supportable. Requires a process change: inspections are captured on arrival at a location with connectivity and queued for upload at the depot. Fails the two-to-four-hour dead-zone need.
- Canvas app with device-local caching. Data is held in local collections, persisted on the device, and pushed when signal returns. Workable but device-bound: no multi-user conflict handling, size limits on local storage, and data at rest on a shared tablet, which is a security question given shared devices.
- Fund a small premium pilot. 38 users on per-app licensing is a bounded, priceable line item. Compare it against the cost of the manual workaround and of losing inspection records, not against a zero budget.
Recommend a canvas app writing to a governed SharePoint list as the near-term deliverable, with the offline gap handled by a depot-sync process change, and simultaneously put option 3 in front of IT with a costed business case. Do not silently build option 2 and call it offline support.
2. If the local-caching route is used, what design decisions and risks must be documented?
Read the worked answer
Caching is a workaround, and the documentation should say so in those words so nobody later assumes offline is a supported feature.
Design decisions to record:
- Sync trigger and identity: what causes an upload attempt, how records are keyed so a retry does not create duplicates (client-generated GUID per inspection, checked on write), and how the app behaves when two inspectors edit the same valve record.
- Conflict policy: last-write-wins is the easy default and is wrong for inspection data; prefer append-only submissions with a supervisor reconciliation queue for conflicts.
- Device state: what happens on battery death, app update, or tablet reassignment mid-queue. Unsent records must survive an app restart, and that must be tested, not assumed.
- Data at rest: shared tablets holding cached inspection data need device-level controls, a screen lock policy, and a wipe-on-reassignment step. This belongs in the risk register, not in a comment.
- Capacity: photo evidence per inspection multiplied by 2,100 per month will strain a SharePoint list; store images in a document library and keep the list to metadata. Cap photo count and resolution in the app.
Risks to log with owners: record loss on device failure, duplicate submissions, stale data reaching supervisors (same-day visibility depends on sync actually happening), and the support burden on a part-time maker. Each risk should have a named mitigation and an acceptance signature from the operations owner.
3. What should the analyst escalate to IT and the center of excellence, and in what form?
Read the worked answer
Escalate three decisions, not a status update.
- Entitlement decision: a costed request for premium licensing for a bounded pilot, with the manual-workaround cost and the record-loss risk attached. Frame it as a decision with a deadline, because the pilot either proceeds or the process change is adopted.
- Data store approval: written confirmation that a governed SharePoint site with defined retention and permissions is the sanctioned store for inspection records, including the photo library. Get this before build, not after.
- DLP interpretation: the policy blocks custom connectors; confirm that standard SharePoint and Office connectors are permitted for this use case, and whether the local caching approach raises any data-at-rest concern that security wants to review.
Put all three in a one-page architecture decision record: context, options considered, decision, consequences, owner, date. Circulate to IT architecture, security and the center of excellence.
The reason to formalize is durability. A citizen-developed app that survives its maker needs an approved platform, an approved store and a named owner. Verbal agreements disappear when the analyst changes role, and the inspectors are left with a tablet app that stopped syncing.