IDDE tracking software: what municipal MS4 programs actually need

The phone rings at 6:15 a.m. A resident saw something coming out of an outfall that does not belong. By the end of the month, the records about that call exist in five places: the dispatch log, an inspector’s phone, a coordinator’s email, a shared drive folder, and a paper notebook. By the next reporting cycle, half of those places no longer exist as findable records. The work happened. The chronology did not survive.

IDDE is the workflow most likely to expose where a program’s documentation is going to fall apart. It happens on someone else’s clock, often involves multiple visits over weeks or months, and frequently spans agencies. A program that does inspections cleanly can still come apart on IDDE, simply because the trail is harder to keep on one record.

This post is about what IDDE tracking software should actually do for a municipal MS4 program. Not the operational walkthrough of how to run an investigation, which is covered in the complaint-to-closure playbook. This post is the software-evaluation version: what to look for, what to skip, and what a good tool does at each stage of the workflow.

What “IDDE tracking software” should mean

The category is loose. Some tools that call themselves IDDE software are basically complaint logs. Others are inspection apps with an “incident” form. A useful working definition: software that holds a single incident record from intake through closure, with every observation, photograph, sample result, and action step linked to that incident, and that produces records the annual report can read directly.

Three structural requirements:

One record per incident, not one record per visit. Multi-visit investigations belong on a single thread.
Every spatial observation tied to coordinates and to the outfall or location it describes.
Every photo, screening result, and field measurement attached to the incident record at the time of capture, not as an afterthought upload.

If a tool stores each visit as a separate row with no parent-child relationship to the original complaint, the chronology is going to break at the next staff transition. The investigation becomes a search problem rather than a record.

The real IDDE workflow, end to end

Most IDDE incidents move through the same arc, and good software should support each stage as a first-class concept rather than a generic form.

Complaint or discovery intake. The first record that exists for the incident. Captures date and time, reporter contact (or anonymous notation), location with coordinates, what was observed, and an initial classification. The intake record sets the response clock. Permits typically require a first action within a defined window, often seven days. Software that does not timestamp intake automatically and surface the response window is asking the coordinator to track that clock manually.

Field screening. The first physical response. An inspector visits the outfall or contributing point, documents flow conditions, indicator panel results, photographs, and any field readings. Screening records belong on the incident, not as standalone inspection records.

Incident classification. Based on screening, the incident is classified as illicit, suspect, permitted, or no observed discharge. The classification can change as more information comes in. Good software keeps the classification history rather than overwriting.

Investigation and source tracing. The longest stage and the one most likely to span weeks. Each upstream step (manhole opened, contributor inspected, sample taken, communication with property owner or other agency) belongs as its own action on the incident thread. The investigation is the chronology, not a summary written at the end.

Source identification. When the contributor is identified, the action transitions from documentation to response. The identification belongs on the incident with the evidence that supports it.

Elimination. The corrective action that stops the discharge. Voluntary cleanup, notice of violation, compliance schedule, or coordination with another agency. Each action belongs on the incident and links forward to verification.

Verification. The follow-up that confirms the discharge has stopped. Re-screening, sample results, photographic evidence. An incident that closes without verification is an incomplete record in an audit.

Closure. The final disposition. Date of cessation, description of the corrective action that worked, evidence behind the closure, and time elapsed from intake. If the source could not be identified, the closure should document what was tried and why further investigation was not pursued.

Evidence retention and annual reporting. Every incident closed during the reporting period feeds the MCM 3 section of the annual report. The count comes from the records, not from a coordinator typing it in. This is where IDDE software either earns its keep or becomes a separate system the coordinator reconciles to the report once a year.

The full inspection workflow that captures field screenings is on the inspections page, and the spatial context that makes outfall-by-outfall investigation legible is on the GIS workspace page.

What buyers should look for

Concrete things to evaluate:

One thread per incident. Open a complaint, walk through three months of activity, and confirm that everything is on one record.
Photo and GPS automatic at capture. Photos taken in the field should attach to the incident with intact EXIF metadata, GPS, and timestamp. If photos require a separate upload step, half of them will go missing. The full evidence guide is in the photo and GPS evidence post.
Outfall timeline. A view that shows every incident, screening, and inspection that has ever touched a particular outfall. Pattern detection at the outfall level is one of the highest-value features, and most generic forms tools do not have it.
Response time visibility. The intake-to-first-action clock should be on screen, not in someone’s head.
Multi-agency handoff. Cross-connections often involve the sanitary sewer utility. Investigations often involve environmental health for septic, hazmat for spills, and code enforcement for property issues. The incident record should handle communications and handoffs without losing the chronology.
Direct feed into annual reporting. The MCM 3 section of the annual report should read from the incident records automatically. Counts derived, not typed. The full reporting architecture is on the reporting page.

Red flags

A few signals worth treating carefully:

One record per visit. If the software stores each visit as a flat row with no parent incident, multi-visit investigations are going to lose chronology.
Manual photo upload. If photos require an explicit upload step rather than attaching automatically at capture, evidence will go missing.
No outfall timeline. Without a per-outfall view, repeat issues at the same outfall read as separate incidents and patterns stay invisible.
Compliance scores generated from sparse data. A “92% compliant” rollup computed from missing fields hurts your program in an audit and misleads council.
Per-user pricing that scales fast. Stormwater programs are small core teams. Per-seat pricing penalizes the right shape.
No export path. If the software cannot export your incident records in a standard format, you are choosing to be locked in.

What IDDE software does not do

Worth being clear about a few limits, because vendor language sometimes blurs them:

Software does not run the investigation. The coordinator and the field staff do. What software changes is whether the chronology survives.
Software does not auto-submit IDDE records to a state agency. The annual report assembles the IDDE summary from the records, but submission is still a human action through whatever channel your state agency requires.
Software does not classify discharges. The inspector does. The software holds the classification and tracks how it changes.
Software does not legally compel a property owner to fix anything. Enforcement is your authority, not the software’s.

Tools that imply otherwise are stretching what the category actually does.

How NPDESTracker approaches IDDE tracking

NPDESTracker structures IDDE as a single thread per incident from complaint to closure. Intake captures the call, screening visits attach photos and field readings, source tracing keeps each step on the same record, and enforcement actions stay linked from initiation through verification. Every photo and GPS coordinate comes off the inspector’s phone directly to the incident at capture. The outfall timeline is automatic. When the reporting period closes, the MCM 3 section of the annual report reads from the incident records without anyone typing counts.

The product is built around the Western Washington Phase II permit and adjacent state programs, with the same federal six-MCM framework that other state agencies use. The fastest way to see how the IDDE thread behaves on sample data is the interactive demo. Pricing starts with the free demo and a $4,900 90-day pilot, with Starter annual plans from $8,000 a year for small Phase II MS4 teams up to 5 users.