The problem
Maintenance requests for an entire area of housing stock do not belong to one team. A single repair can pass through the housing team, a surveyor, one of several internal trades teams and an external contractor before it is closed, and each hand-off is a chance for the request to stall, be duplicated, or lose its history.
- No single view of a request from report to completion: each party kept its own record of its own part.
- Hand-offs between teams, surveyors and contractors relied on email and phone, so ownership and status were often unclear.
- Management had no reliable, live picture of open requests, backlogs or contractor performance.
- Housing maintenance carries compliance obligations, so the who-did-what-when trail needs to be complete and defensible.
What I built
- One request record, end to end. A model-driven app on Dataverse where every maintenance request is a single record that moves through the lifecycle (reported, triaged, surveyed, assigned, in progress, completed) with the current stage visible to everyone involved.
- Structured hand-offs. Surveyor inspections and contractor work orders are linked child records of the request, so assigning work is a step in the process rather than an email, and the request always knows who owns it now.
- Multi-party working. Internal teams, surveyors and contractors work in the same system with views tailored to their role: a surveyor sees inspections due, a contractor sees the jobs assigned to them, the housing team sees everything.
- Automation around the record. Power Automate handles notifications on assignment and status change, and reminders when a request has sat too long at one stage.
- Reporting. Dashboards and views for the housing team on open requests, ageing and throughput by team and contractor.
Data model & security
The model is built around the request. Properties, requests, inspections, work orders, teams and contractors are separate Dataverse tables joined by lookups, so a property’s full maintenance history and a contractor’s full workload are both one query away. Controlled values (categories, priorities, statuses) live in option sets rather than free text.
Access is enforced by Dataverse security roles: each party can only see and edit the records relevant to them, contractors are limited to their own work orders, and the platform’s built-in auditing gives a complete change history for every request.
Why model-driven
Model-driven over canvas
This is a process-heavy, data-heavy system with many related tables and many user roles. A model-driven app gives forms, views, dashboards, business process flows and role-based security out of the box, so the effort goes into getting the data model and the process right rather than into building screens.
Dataverse from day one
Relational integrity between requests, inspections and work orders, row-level security between parties, and native auditing were hard requirements: the same criteria that pointed to Dataverse on the KPI platform.
Impact
- One shared, current record per request instead of several partial ones: no more chasing across teams to find out where a repair is.
- Clear ownership at every stage, with hand-offs and reminders handled by the system.
- A live picture of backlogs and throughput for the housing team and management.
- A complete audit trail for a compliance-sensitive service.
Skills demonstrated
- Model-driven app development
- Dataverse data modelling
- Security roles & row-level access
- Business process design
- Power Automate
- Multi-stakeholder delivery