Most backflow programs do not fail all at once. They erode one missed test at a time, until a state audit reveals that a few hundred assemblies are overdue, a handful of tests were signed by a tester whose certification had lapsed, and nobody can quickly say which is which. Backflow tracking software exists to stop that slow erosion.
This guide is about the tracking itself: what data a backflow program has to hold, how the test lifecycle should be automated, and how to build it on tools a water utility likely already owns. For the wider program around it, hazard surveys, policy and enforcement, see our guide to cross connection control software.
What is backflow tracking software?
Backflow tracking software is a system that maintains a water utility’s inventory of backflow prevention assemblies and manages their testing lifecycle, from scheduling the annual test through recording the result, chasing overdue tests and confirming the tester was certified.
It has to track four things reliably:
- Every assembly, its type, location and the hazard it protects against
- The test schedule and the full test history per assembly
- The certified testers and the current status of their credentials
- The follow-up state: due, tested, passed, failed, overdue
The data model is the whole job
Backflow tracking looks simple until you map the relationships, and the relationships are where spreadsheets break.
An assembly belongs to a customer and a service connection. It has a type and a hazard rating. It has many tests over time, each with a date, a result and a tester. A tester has a certification with an expiry date. A test is only valid if the tester’s certification was current on the test date. Miss any of those links and the program has a hole: a valid-looking test that was not, an assembly assigned to the wrong customer, an overdue device hiding in a column nobody sorts.
A spreadsheet cannot enforce those relationships. It will happily accept a test dated after a tester’s certification expired, or let an assembly exist with no customer. Real tracking software enforces the model, which is the entire point. The interface matters far less than whether the data can be wrong.
The test lifecycle should run itself
The second half of the job is time. Every assembly is on an annual clock, and the clocks are all offset from each other, which is precisely the kind of work software should handle and people should not.
A good setup moves each assembly through its lifecycle automatically: it flags the assembly as due ahead of the anniversary, sends the customer a notice, records the test when the result comes in, validates that the tester was certified on that date, and escalates to an overdue notice if the window passes. The staff job shifts from chasing dates to handling the exceptions the system surfaces, which is a far smaller and more manageable task.
COMPLIANCE ON MICROSOFT 365
Want the test cycle to chase deadlines for you?
Nexinite builds assembly tracking and an automated test lifecycle into the Microsoft 365 your utility already runs, so overdue tests surface themselves. In your own tenant, no forever licensing.
Building it on Microsoft 365
A water utility running Microsoft 365 already licenses the parts a backflow tracker needs, and most do not realise the data model is well within reach.
Dataverse or SharePoint can hold the related tables, assemblies, tests, customers and testers, with the relationships enforced so a bad record cannot be entered. Power Automate runs the annual clock, the reminders and the overdue escalations, and can check tester certification dates on every submission. Power Apps gives field staff a mobile form to record a test on site. Power BI shows the compliance rate and the overdue list at a glance.
On licensing: E1, E3 and E5 include seeded rights to build Power Apps and Power Automate over SharePoint, and E5 includes Power BI (Microsoft Power Platform Licensing Guide, August 2026). The relational model is where Dataverse earns its Power Apps Premium cost, and for a backflow program the enforced relationships are worth it. Even so, the total sits well below a per-assembly subscription for a niche product, with the data in a tenant you control.
Buy or build for backflow tracking
| Capability | Niche backflow product | Built on Microsoft 365 |
|---|---|---|
| Relational data model | Built in | Dataverse, enforced |
| Automated test cycle | Built in | Power Automate |
| Field test entry | Included | Power Apps |
| Tester self-submission portal | Common | More setup required |
| Compliance dashboard | Vendor reporting | Power BI |
| Data ownership | Vendor environment | Your tenant |
As with the broader program, the deciding factor is usually the tester portal. Many independent testers submitting directly favours a product that ships that portal. A program run mostly in-house favours building on what you own.
Why data ownership matters here
Backflow records are compliance evidence, sometimes for decades. If they live in a vendor’s system and you change vendors, or the vendor changes terms, that history is suddenly a migration project or a hostage. Building the tracker on your own Microsoft tenant keeps the evidence in infrastructure you control, which also simplifies public records and retention obligations. This is the same own-your-data logic behind our guide to utility asset management software.
Frequently asked questions
What is backflow tracking software?
It is a system that maintains a utility’s inventory of backflow prevention assemblies and manages their testing lifecycle: scheduling annual tests, recording results, chasing overdue tests, and confirming each test was done by a currently certified tester. It exists to keep a large, staggered set of test deadlines from slipping.
How is this different from cross connection control software?
Backflow tracking is the assembly and test-cycle core. Cross connection control is the wider program around it, including hazard surveys, policy, customer notification and enforcement. The tracking is the engine inside the larger program.
Can we build backflow tracking on Microsoft 365?
Yes, and the relational data model is the reason to consider Dataverse specifically. It can hold assemblies, tests, customers and testers with the relationships enforced, Power Automate runs the reminders and overdue escalations, and Power BI shows the compliance rate. Most of this uses licences you already hold (Microsoft Power Platform Licensing Guide, August 2026), with Dataverse the main paid add-on.
Why not just use a spreadsheet?
Because a spreadsheet cannot enforce the relationships that make the data trustworthy. It will accept a test dated after a tester’s certification lapsed, or an assembly with no customer. At a few hundred assemblies that is manageable, at a few thousand it is a compliance gap waiting for an audit.
Where to start
Get the assembly-to-test-to-tester relationships into a real data model that will not accept a bad record, then automate the annual clock so overdue tests surface themselves. Both are within reach of the Microsoft tools most utilities already own.