What you will learn
- What backflow devices do and where they are required
- How device inventory, test schedules, and tester records fit together
- What a test result contains and what a failure triggers
- How customer notifications and enforcement work
- What regulators require in backflow reporting
What the project is
Backflow happens when pressure reverses and water flows backwards from a customer's premises into the public supply, carrying contaminants from boilers, irrigation systems, fire systems, or industrial processes. Prevention devices, such as reduced pressure assemblies and double check valves, stop that reversal. Most jurisdictions require devices at high-risk connections and require them to be tested annually by a certified tester, with results reported to the water supplier.
Tracking software holds the device register: each device's location, type, size, installation date, and hazard level, linked to the customer and premises. It schedules annual tests, records results from testers, flags failures and overdue tests, notifies customers, and escalates non-compliance. Without it, a utility with thousands of devices cannot know which ones are overdue, and the protection the devices offer becomes theoretical.
Core features
Overdue visibility is the feature. A register that cannot show, today, which devices are untested is not a compliance tool.
- Device register with type, size, location, hazard level, installation date, and linked customer and premises.
- Test scheduling by due date, with automatic scheduling for annual tests and reminders to customers and testers.
- Tester management: certification records, expiry dates, and authorisation, so only certified testers can submit results.
- Test result entry with pass, fail, and repair outcomes, and the retest workflow for failed devices.
- Customer notifications: test due, test overdue, and failure notices, with clear instructions and deadlines.
- Enforcement workflow: escalation steps for persistent non-compliance, recorded per device and customer.
- Compliance reporting: tested, overdue, failed, and repaired counts by area and hazard level, for regulator filings.
How it is built
Start with the register, because a test schedule built on a bad register schedules tests for devices that moved, were removed, or never existed.
- Register cleanup: import existing device records, verify locations and types, and resolve duplicates before building anything else.
- Schedule and tester build: due-date scheduling, tester certification records, and result entry, tested with real testers.
- Notification and enforcement: customer notices, overdue flags, and escalation workflows, agreed with compliance staff.
- Reporting: compliance summaries generated from the register and test records, validated against a past filing.
- Field tools: mobile result entry for testers on site, with offline tolerance for premises without connectivity.
Tech considerations
This is a register and workflow product. Data accuracy and scheduling reliability matter more than any advanced feature.
- Device data model with premises, customer, device, and test history linked, so a device that changes owner keeps its history.
- Scheduling engine with due dates, grace periods, and recurrence rules that match the regulatory cycle.
- Tester portal with certification checks at login, so an expired certification blocks result submission.
- Notification integration for email and postal workflows, because not every customer can be reached digitally.
- Role-based access separating utility staff, testers, and customers, with an audit trail on test results.
Challenges to plan for
Backflow programs fail on register accuracy and on enforcement that stops at the first reminder. Both leave devices untested.
- Register decay: devices are replaced, premises change hands, and the register drifts from reality within a year if nobody maintains it.
- Tester capacity: a small pool of certified testers cannot test thousands of devices in a short window, so scheduling must spread the load.
- Customer inaction: many customers ignore a test notice until enforcement begins, and the escalation path must be real, not decorative.
- Failed device follow-up: a failed device that is not repaired and retested promptly is worse than an untested one, because it is known to be broken.
Who it is for, and honest limits
This fits water suppliers with backflow programs, from cities to rural districts, and the testing firms that serve them. It fits less well for a system with a handful of devices, where a list and a calendar may honestly be enough.
It does not test devices or certify testers. It makes testing scheduled, recorded, and enforced. If the tester pool is too small or enforcement has no teeth, the software will show the gap clearly, but closing it needs people and policy.
Frequently asked questions
What is backflow?
Water flowing backwards from a customer's premises into the public drinking supply, caused by a pressure reversal. It can carry contaminants from boilers, irrigation, fire systems, or industrial processes into water other customers drink.
How often must devices be tested?
Usually annually, though requirements vary by device type, hazard level, and jurisdiction. Check current requirements for the operating area rather than assuming a standard cycle.
Who can test a device?
A certified backflow tester, with certification recorded and current. The system should block result submission from testers whose certification has expired.
What happens if a device fails its test?
It must be repaired and retested, usually within a defined period. The system tracks the failure, the repair, and the retest as one workflow, and escalates if the retest does not happen.
What if a customer ignores test notices?
Escalation follows the utility's enforcement path: further notices, then the enforcement steps defined by its rules, which may include service consequences. The system should record every step, so enforcement is consistent and defensible.