A special district and a municipality are both forms of local government, but they are built to do very different things. Municipalities are general-purpose governments, responsible for a broad range of functions. Authority is spread across everything from zoning and building oversight to public safety and infrastructure. A special district is an independent local government created to provide one specific public function, such as water, sewer, drainage, fire protection, irrigation, or parks and recreation. It operates separately from any municipality or county whose territory it overlaps, with its own governing board, revenue authority, and jurisdiction over that function. And while its mandate is narrow, its authority within that mandate is complete. For a water or sewer district, that means its entire permitting responsibility centers on its own infrastructure: the pipes, the connections to them, and the treatment obligations that come with them. It doesn’t issue building permits or certificates of occupancy, and it has no zoning authority.

Special districts are far more common than many people realize. The U.S. Census Bureau counted 39,555 special district governments in its 2022 Census of Governments, more than twice the number of municipal governments nationwide. Among them are 3,550 water supply districts, 2,541 soil and water conservation districts, 2,419 drainage districts, 1,829 sewerage districts, 1,457 parks and recreation districts, 955 irrigation districts, and 599 flood control districts.

This scale hasn't shaped the software available to special districts. Nearly every permitting and licensing platform is designed around how a municipality operates only and then adjusted at the margins for other types of users. As a result, many special district managers, engineers, and operations leads work in a software system that was never built for them and mishandles the fundamentals of their job — what a district permits, which responsibilities continue beyond individual projects, who performs the work, and whether applicants even know the district has jurisdiction.

Four conditions account for most of this mismatch. Each one is routine inside a district but unfamiliar to software designed for a municipal building department. Together they make a useful test for special districts evaluating permitting software to streamline their work and simplify the experience of the public.

‍

A District Permits a Connection, Not a Building

Most municipal permitting systems start with a building or structure on a parcel. A special district starts with the point where a property connects to its system. For a water or sewer district, tap and connection permits — not building permits, zoning approvals, or certificates of occupancy — sit at the center of that process. Software built for a utility-only jurisdiction should reflect that narrower scope, so staff aren’t navigating around building, zoning, and occupancy modules they’ll never use, or adapting workflows for approvals they don’t issue. That connection-first model changes several basic requirements for the permitting system, including how the permit record is configured in the platform.

Tap and connection permits are the primary permit type

Tap and connection permits are among the highest-volume permits a water or sewer district processes. They should function as their own digital record type, allowing applicants to apply, pay fees, and schedule inspections online while staff track progress in one place. That moves the district beyond paper intake and manual tracking without forcing its primary permit type into a workflow originally designed for a municipal building department.

The connection may exist before the address

District involvement can begin while a subdivision is still being built, often before individual lots have street addresses. Special district software should be able to identify a future connection using a parcel identifier or GIS pin instead of a confirmed address, as may be required in municipal permitting software. Otherwise, address validation can block an application even though the location that matters to the district — the connection point — already exists.

The relevant contractors are different

The contractor registration process needs to reflect a special district’s jurisdiction, too. Municipalities may be accustomed to registering general contractors within their software application. Special districts may need to register trade-specific contractors like plumbers and irrigators separately from general contractors and adjust permission sets and routing rules on an individual-basis. That lets the special district track the people authorized to touch its system instead of inheriting the broader contractor categories a municipality needs to manage.

These requirements aren't met by simply reconfiguring settings within an existing permitting process. For software that matches how the work actually happens, special districts need a permitting model that starts from the connection rather than the building.

‍

Compliance Programs Run Continuously

A permit has a natural endpoint. An application comes in, staff review it, inspections happen, and the permit is issued or closed. Some of a special district's most important regulatory responsibilities don't work in such a sequential manner. They attach to a device, a facility, or a piece of infrastructure rather than to a project, and they remain in force for as long as that asset stays subject to the district's requirements. A water district administers cross-connection control. A sewer district oversees pretreatment and grease requirements at commercial facilities. A fire district collects annual testing reports on sprinkler and alarm systems. A drainage district tracks maintenance obligations on detention basins even after the subdivision that built them is finished. Software built only around one-off projects can leave special districts managing these recurring obligations in spreadsheets and disconnected files.

Certifications recur on a fixed cycle

Many district requirements have to be re-verified year after year by a licensed professional who doesn't work for the district: a certified backflow tester, a sprinkler contractor, a licensed operator. Special district software needs to give those outside professionals a way to submit results directly, and to track expirations and renewal reminders automatically. That keeps the annual cycle in one system instead of depending on staff to maintain and remember to check a separate spreadsheet.

Obligations follow the asset, not the permit

Requirements may begin with an application, but a special district's responsibility can continue well past the point where the permit closes. Pretreatment and fats, oils, and grease (FOG) requirements stay with a restaurant for as long as it operates and a detention basin carries maintenance obligations for the life of the development. Software should keep surveys, notices, agreements, and related requirements tied to the facility as part of the same workflow. That gives staff one continuing record instead of a permit file in one place and a parallel program file somewhere else.

Special districts have responsibilities that don't end with a single permit. They are required to track facilities, outside participants, and recurring requirements over time. As a result, the software they use needs to support an ongoing program, not just a project with a defined end date.

‍

Review and Inspection Steps Include Third-Party Professionals

A special district's process doesn't always move through a fixed set of internal staff. Plan review may sit with an outside consulting engineer, and on a multi-year buildout the contractor who starts the work often isn't the one who finishes it. Neither of them is a district employee, and neither is guaranteed to be there for the whole project. Permitting software has to hold the process together across these changes, preserving the permit and its history when participants turn over, and enforcing the district's own sequencing and fee rules rather than leaving them to staff memory.

Outside engineers are part of the review process

Consulting engineers are often responsible for the plat and infrastructure review even though they aren't on the district's payroll. Software should let them review plans and submit comments as users directly in the system. This helps keep version history and the audit trail attached to the project instead of scattered across email threads and attachments.

Contractors can change before the project is finished

A subdivision buildout can last for years, and the contractor who starts the work may not be the one who finishes it. A special district permitting system needs to accommodate contractor changes while preserving the existing permit, with the property owner authorizing who can act on it. A mid-project change shouldn’t require staff to reissue the permit or reconstruct its history.

Inspection order can be a requirement

A single connection permit often carries several inspections that have to happen in a fixed order. On a water tap, the line is inspected before it's covered, the system is pressure tested, and a final customer service inspection confirms there are no cross-connections before service is released. 

Special district permitting software should hold this order as a rule rather than a convention. Each inspection should stay unavailable until the one before it passes, so a contractor scheduling online can only request what's actually next, and a failed inspection reopens the steps behind it instead of letting the sequence run forward. The district defines the order once, and the workflow keeps it without a staff member watching the queue.

Different inspections can follow different fee rules

Inspection billing can vary by type. A water inspection might carry a flat fee no matter how many visits it takes, while a sanitary sewer inspection is billed per trip, so a failed inspection and a return visit are two charges rather than one. The contractor scheduling that return visit has no reason to know which rule applies, and no way to price it. When the logic lives in the software, the charge attaches automatically the moment the trip is scheduled and the contractor sees it before the inspector is dispatched. When it doesn't, someone on the special district staff has to notice the re-inspection happened, look up the rule, and add the charge manually to ensure billing is accurate.

‍

The District Is Invisible Until It Isn't

A contractor can pull a permit from a city, mobilize a crew, and open the ground before learning that another government has jurisdiction over the connection. Special districts can overlap several municipalities or serve unincorporated areas, so an applicant who has cleared every requirement they knew about may still be missing one. A better internal workflow can't solve that problem if the applicant doesn't know the special district exists.

This is a discoverability problem before it's a workflow problem. The special district's internal process may be sound, but the applicant simply never experienced it. In this case, the fix is a public front door rather than a better back office.

A public portal makes the district findable

The applicant-facing permitting portal is the district's front door. A contractor or resident searching for requirements at a project address should land on a public page hosted by the special district and be able to review requirements and submit applications in one place. As a result, applications arrive complete, at the start of a project rather than in the middle of one, and the special district becomes a routine step in the process instead of an afterthought. This creates a better experience for applicants, too, with clearer guidance, transparency, and status updates as they navigate through the process. 

Applicants need to know which government they’re dealing with

Once an applicant is working with two governments, the paperwork has to distinguish them. Permitting software should let a district carry its own prefix, so its permits are never mistaken for the neighboring municipality's. This is a small requirement, but one that has a meaningful impact, helping tell a contractor holding two approvals which government issued which, and makes it easier for staff to find the records they need.

‍

How to Tell if Permitting Software Fits a Special District

The differences between municipal and special district permitting aren't always obvious in a software demonstration. A platform can handle applications, payments, and inspections well and still be built around a municipal model. These five questions can help reveal whether the underlying workflows best fit the needs of a special district:

• Can you open a permit without a validated street address? Look for parcel identifiers and GIS locations, since a connection often exists before the lot has an address.
• Are recurring compliance obligations built into the system? Annual certifications and facility requirements shouldn't have to be forced into permits designed to close.
• Can outside consulting engineers work directly in the platform? Reviews and revisions shouldn't have to move into email, and version history should stay with the project.
• Can inspection fees vary by type and by trip? Flat fees, per-trip billing, and repeat visits should all be configurable and priced automatically.
• Is there a public-facing portal applicants can reach on their own? A contractor who searches for requirements at a project address should find the special district’s site and be able to apply there, without a staff member setting up access first.

How GovWell Helps Special Districts

GovWell is purpose-built for local governments and configured to handle the workflows special districts actually run. Rather than adapting a municipal permitting model to fit a narrower jurisdiction type, GovWell configures its platform around what a special district actually permits and what it is responsible for after that permit closes.

Every special district operates under its own mandate, and the requirements that follow from it vary widely. The GovWell team can walk through yours and how those workflows would map to its modern operating system.

Schedule a conversation with our team.