Declarations Application Rebuild
Staff use this application to declare conflicts of interest, secondary employment and gifts received. It is, by definition, a system that exists to be audited — and its audit trail didn't actually show who did what.
The challenge
I inherited it. It had been built as a canvas app and then added to, repeatedly, without anyone stopping to interrogate the design as it grew. Around thirty cloud flows. No retry logic or error handling. Deployments were manual exports and imports with no version control.
Privileged accounts were performing actions on behalf of users — writing and sharing their records — which meant the audit trail showed a service account acting rather than the person who had actually made a declaration. On this data, that isn't a technical defect; it's the system failing at its only real job.
The approach
The harder problem was trust. This team were downstream consumers of a separate establishment data pipeline, so we already interacted mostly through bugs. Much of what they experienced as a broken app was upstream source data, but the effect was the same: they had stopped believing what we told them. So I didn't open with a rebuild. I said plainly that the architecture couldn't perform, then did everything available short of replacing it — moving data transactions out to Power Automate so the app wasn't filtering data on the device, adding the error handling that was entirely absent. Alongside that I set the expectation honestly: this helps, but there is a point where we have to stop and start again.
When we reached that point, I put up two costed options. Rebuilding in canvas was the trodden path — no architecture board, no approvals — but slower to build and still bound by Power Platform's UI constraints. A code app meant real control over the experience, including taking the NSW Government Design System as a dependency so the app matched other government systems staff already use, and a shorter build. It also meant architecture board, approval board and change advisory. I priced the governance effort as a line item rather than a footnote, because on this decision it was the actual trade-off — and I'd benchmarked iteration times between the two approaches rather than arguing from preference.
Enterprise architecture was where it got hard. Plugins were already approved technology; code apps were not, and there was a tenant-wide misconception that a code app was essentially a web page that could download and execute arbitrary code, rather than a sandboxed browser session. Clearing it took explaining Power Platform's architecture in depth and demonstrating security in engineering terms — GitHub Advanced Security, source control in Azure DevOps, deployment pipelines, full ALM.
Architecture
I deliberately did not bundle a second change into that approval. Once the code app was built and demonstrably working, I made a separate case for moving business logic out of cloud flows into Dataverse plugins: first-party data touches produce a real audit trail, the architecture simplifies, removing the app-to-flow-to-Dataverse round trip gains more performance again, and protections can be built at the data layer.
Outcome
Built solo in roughly four weeks, with two weeks of testing and go-live support. Cloud flow count dropped by two thirds. Shortly after release, submissions began failing intermittently; because the rebuild included granular error capture and telemetry, the reports carried distinct timestamped errors that cross-referenced directly against the logs. Root cause — a conditional branching fault in a plugin — was found, fixed, tested and deployed inside two hours. Under the old architecture the same fault would have meant reading cloud flow run histories with nothing tying a user's report to a failure.
It was the department's first production code app, and the components built for it became the foundation of the shared component library the department now builds on.