Replacing a Partial Microsoft Form with a Composable, Multi-Type Incident Reporting Platform

The Problem

A two-year-old process that was never designed for the job

A county government agency with operations spread across a large jurisdiction encounters incidents across five categories every month: employee injuries, vehicle collisions, property damage, non-employee injuries, and near misses. The prior reporting process had been in place for over two years and had never been designed to handle all five. A Microsoft Form covered a partial subset of incident types. Submissions flowed into a manual Excel export that required someone to review and communicate findings by hand. There was no automated notification routing, no structured data model, and no queryable incident record.

When the employee who owned that process left the organization, the process lost its institutional owner. What remained was an incomplete intake form, a manual data chain, and 40–50 incidents per month that continued to occur regardless of whether the system was equipped to handle them.

The Approach

Composability as the design principle

The design was organized around one central insight: real-world incidents do not conform to mutually exclusive categories. A county vehicle collision can simultaneously be an employee injury event, a non-employee injury event, and a property damage event. A reporting system that forces a single incident type selection loses data. The architecture was built around composability — a single parent incident record as the universal entry point, with child records for each applicable incident type written atomically at submission.

Three architectural decisions shaped the implementation. First, the app uses no Power Apps Edit Form controls — all form state is held in global variables and collections, all writes deferred to a single Patch sequence at submission. Second, all binary columns use a global Dataverse choice set rather than native boolean columns, ensuring a blank value cannot be misread as a negative answer. Third, severity was designed as a structured routing input with specific severity scales — the KABCO scale for vehicle collisions, a three-tier occupational health classification for employee injuries — so that escalation logic is deterministic, not subjective.

The Solution

A variable-driven, composable intake platform with severity-based routing

The Incident Reporting Application (IRA) Canvas App is a variable-driven, multi-screen guided intake system. An employee selects their incident type at the entry screen. The app routes them through only the screens and conditional fields relevant to that selection. Ten valid incident flow combinations are supported, including cross-triggered child records: an employee injury can trigger a vehicle collision child record, a vehicle collision can trigger employee or non-employee injury child records, and all three can be combined in a single parent incident.

The Review/Submit screen renders a unified read-only view of all in-memory state before the employee confirms. On submission, a single atomic Patch sequence fires — the parent incident record is created first, each child record written using the returned parent lookup, witness and attachment records written by looping their respective collections. No partial records are created at any point during navigation.

Power Automate flows trigger on record creation and dispatch notifications via Microsoft Teams, routing by incident type and severity. Any submission notifies the safety administrator. Employee injuries at Limited Duty or Lost Work severity and vehicle collisions at Major or Critical severity escalate to senior leadership and the supervisor of record. A parallel model-driven app gives the safety administrator a structured Dataverse interface for investigation management.

Outcomes

Three weeks. Executive sign-off. Full organizational coverage.

Transferability

Where this pattern applies