A municipal Phase II MS4 program runs differently from the program in the next county. Different permit framework, different BMP types, different terminology, different site classifications, different inspection cadence rules. Modern stormwater software should treat this as the normal case, not as a custom engagement.
This post is a working list of what a Phase II program should be able to change in its own workspace, without filing a paid services ticket and without writing custom code. The framing assumes a small or mid-sized city, county, or special district.
Modules the program does or does not run
Not every Phase II program does every MCM the same way. Some programs run a strong public education program. Some outsource MCM 1 to a regional partner. Some have a robust source-control inspection program. Some have a handful of sites and run source control as a quiet quarterly walk.
The workspace should reflect that. A municipality should be able to turn modules on or off so the dashboards, the navigation, and the My Work view only show what the program actually runs. Turning off a module should not hide records that already exist; it should just stop putting that module’s surfaces in front of users.
Terminology that matches the program
Words matter. If your program calls them “outfalls” and the workspace calls them “discharge points,” the inspector writes the discharge-point form looking for outfall information. Five years later, an audit reviewer reads the records and cannot tell whether the program meant the same thing the software meant.
The workspace should let a tenant administrator rename labels to match the program’s vocabulary. “Catch basin” or “drainage structure” or “inlet”: whichever the program uses, the form uses. The renaming is a label change, not a concept change; the underlying data model stays consistent across customers.
Configurable inspection fields per kind
A construction site inspection in a desert program asks different questions than the same inspection in the Pacific Northwest. A source control inspection at an auto repair shop asks different questions than one at a restaurant. Inspection forms should be configurable per inspection kind.
What configurable means in practice: which fields show on the form, which are required, what the labels say, what order they appear in. The fields themselves draw from the platform’s structured field types (text, number, date, photo, GPS, dropdown, multi-select, etc.); the configuration is which fields appear where.
Editable dropdown values
BMP types vary by region. Bioswale variants. Vault types. Soil amendments. The catalogs are not universal. A municipality should be able to edit the dropdown values on inspection forms in its own tenant without asking the vendor.
Same for finding categories (“deficient silt fence” is not the same finding everywhere) and enforcement actions (“courtesy notice” exists in some programs and not others).
Custom modules from configurable building blocks
A configurable platform should expose small custom modules as a configuration choice, not a custom engineering quote. A new record type built from existing field types and existing workflow patterns is configuration. The tenant administrator defines the record, the fields, the dropdowns, and the workflow steps.
The honest line: this is small custom-module composition, not unlimited custom development. A truly new platform capability (a workflow concept that does not yet exist) is custom engineering, scoped separately. But “we need a new record type for catch-basin lifts” is configuration.
Display settings, default views, and dashboard widgets
The supervisor sees a different default view than the inspector. The IDDE coordinator sees a different My Work than the construction inspector. The dashboard widgets that matter for one role do not matter for another.
A tenant administrator should be able to set defaults per role and let users adjust within those defaults. None of this is custom development. It is workspace personalization that should ship.
Site, contact, and asset inventories from standard formats
Importing the site list, the contact roster, and the asset inventory from CSV, GeoJSON, or shapefile should be a self-service workflow. Not a “data services” line on a quote.
The platform should ship with import templates that match the structured field types. A program brings its data; the import respects the field types; the workspace is populated.
What is fair to scope separately
A short list to keep honest:
- A workflow concept the platform does not yet support. Not “we want a new dropdown value”; that is configuration. “We want a record type that mirrors a state-specific BMP certification process the platform has never modeled” is custom engineering.
- A bespoke integration. A regional reporting portal with a proprietary file format. A non-standard data feed. These are real engagements.
- A substantial historical data migration. “Map 15 years of inspection PDFs into the new record schema.” This is not configuration; it is data services.
- Custom procurement work. Substantial contract redlines, agency-specific compliance procedures, or non-standard agreements. Fair to quote separately.
How NPDESTracker draws the line
NPDESTracker is being built around included self-service configuration. Module toggles, terminology, configurable fields, dropdown values, custom modules from configurable building blocks, display settings, and standard format imports are part of every annual plan.
The full breakdown is on configurable stormwater software. The platform side is on the platform configuration section. What is included with each annual tier is on the pricing page.
Custom engineering beyond the platform configuration tools is scoped separately during a kickoff conversation, with a written quote before work starts.
To see how the configurable workspace looks on sample data, try the demo. The 60-day Guided Pilot is the most common starting point. The inspection-cluster overviews are on stormwater inspection software, MS4 inspection software, and digital stormwater inspections.