.png?width=80&name=Untitled%20design%20(2).png)
ViewPro
An ERP permitting module can be enough for a city with simple, low-volume permits and few departments involved. GIS-based software tends to fit better when one property ties together zoning, permits, inspections, code cases and public works.
The reason is structural. Most ERPs are organized around accounts and transactions, while community development work is organized around places.
If your staff keep a spreadsheet beside a "unified" system, or open a separate map to check what a permit record can't show them, the module is probably the wrong foundation for that work. Keep the ERP for finance, and give community development a system built around the parcel.
Which one fits your city?
Use this comparison as a first pass. Most cities will land in both columns, so look at where your biggest problems sit.
| Your situation | An ERP module may be enough | GIS-based software is likely a better fit |
|---|---|---|
| Permit mix | A few standard permit types with similar steps | Many permit types with different review paths |
| Location rules | Few overlays or site-specific conditions | Zoning, overlays or floodplains often affect review |
| Departments | One or two teams handle most of the process | Planning, building, code and public works all touch the same properties |
| Field work | Light inspection volume, with little need for property history on site | Inspectors and crews need property history in the field |
| Public questions | Routine questions are manageable by phone | Zoning and status questions take up significant staff time |
| GIS use | Maps play a small part in daily decisions | The city already relies on GIS, especially Esri ArcGIS |
Why an ERP sees permits differently
An ERP is very good at questions like these: How much was invoiced? Which fund did it post to? Who approved the purchase? Those answers depend on consistent rules across every department, which is why cities want one financial system.
Community development staff ask a different set of questions:
- What is allowed on this lot?
- Is it inside a floodplain or an overlay district?
- What permits are open at this address?
- Is there a code case next door?
- Which reviewers need to see this application, given where the project sits?
Every one of those questions starts with a location. In many ERP modules, the address is a field on a transaction record. In a GIS-based platform, the parcel is the record that permits, inspections, cases and work orders attach to.
Some ERP suites now offer map views or connections to Esri, so the existence of a map proves little. The useful test is what the map does. Can staff start from a parcel and see everything tied to it? Can zoning or an overlay shape how an application is reviewed? Or is the map a picture attached to a record?
Where the gap shows up
The difference is easiest to see in ordinary moments of the workday.
| Moment in the work | When location is a field | When the parcel is the record |
|---|---|---|
| "What can I build here?" | Staff check the zoning map, the code and permit history separately | Zoning, allowed uses and history for the parcel appear together |
| Application review | Reviewers confirm overlays and nearby activity by hand | Reviewers see the parcel's zoning, overlays and open activity with the application |
| Field inspection | The inspector looks up history in advance and enters results later | The inspector opens the property on site and logs the result there |
| Code enforcement | Cases sit in a separate log that permit staff may not check | Open cases appear on the same property as permits |
| Public works | Work orders live in another tool | Work orders and assets sit on the same map |
| Resident questions | Answers come by phone or at the counter | Residents look up their parcel and zoning online |
| Leadership reporting | Someone exports and merges spreadsheets | Leaders see activity and patterns by area |
One system and one source of truth are different goals
Leaders who want everything in the ERP have good reasons. Fewer vendors mean fewer contracts, fewer logins and fewer integrations to maintain. A second platform does add a vendor and a connection that someone must own.
Still, a single system doesn't guarantee a single version of the facts. If an ERP module holds its own copy of parcels and addresses, that copy can drift from the city's GIS. When staff export records to spreadsheets to finish their work, the city has more versions of the truth, inside a system meant to prevent them.
A more practical goal is one authoritative source for each kind of information. The ERP stays authoritative for money. The GIS stays authoritative for place. Community development software sits between them and handles the day-to-day work, while fee and payment data still need a defined path to finance.
Put a number on the "free" module
A bundled permitting module can look free because it doesn't add a line to the budget. Its real cost is staff time, and you can estimate that with four numbers from your own department:
Annual cost = weekly inquiries × hours per inquiry × 52 × hourly rate
Here is an illustrative example, using made-up inputs. A department handles 150 routine zoning and status inquiries a week, at 10 minutes each. That comes to 25 hours a week, or 1,300 hours a year. At a loaded rate of $40 an hour, those inquiries cost $52,000 a year.
Not all of that time disappears with better software, and some inquiries will always need a person. Even so, the calculation turns a vague complaint into a figure a city manager can weigh.
Some costs are harder to count but still belong in the discussion. Slow reviews delay permit fees, hold up construction and push back the tax revenue that finished projects bring in.
Audit ten applications before the next ERP meeting
The strongest case for change comes from your own records. Set aside a few hours and trace ten recent applications:
- Choose a mix of permit types, including at least one that went badly.
- Follow each application from the first inquiry to the final inspection.
- List every system, spreadsheet, inbox and paper file it touched.
- Count the pieces of information someone typed more than once.
- Note each time staff left the system to check a map.
- Count the applicant calls and visits about status or zoning.
- Mark where the application waited longest, and why.
Then replace general frustration with findings. "The system is clunky" is easy to dismiss. A count from your own files, in the form "X of ten applications required staff to leave the system to confirm zoning," is much harder to ignore.
Tie each finding to something leadership already tracks: turnaround time, staff capacity, fee collection or resident complaints.
Questions to ask any vendor, including your ERP vendor
Ask each vendor to answer these using your city's real parcels, including a difficult one such as a split lot or a property under several overlays.
- Parcel data: Do you use our authoritative parcel and address layers directly, or keep a copy? If you keep a copy, how does it stay current?
- Location logic: Show us how a parcel's zoning or overlay affects the review of an application.
- Map-first work: Can staff start from the map and see every permit, case and work order on a property?
- Field work: What can an inspector or crew member do on site, and what happens when the connection drops?
- Public access: What can a resident or contractor find out without calling us?
- Finance connection: How do fees and payments reach finance? Which records move, how often, and who fixes a failed transfer?
- Departments: Do code enforcement and public works share records with permitting, or only exchange reports?
- Implementation: Who configures the system, and what experience do they have with local government planning and GIS?
- AI: Which tasks does AI handle today, what data does it use, and how do staff check its answers?
Where MuniSync fits
MuniSync is ViewPro's community development platform, built with Esri ArcGIS. It connects GIS, codification platforms and departmental systems into one shared view, so departments work from the same context and cities get more from the GIS they already have.
- Planning and zoning: Map zoning and land use, and bring plans, data and community input together.
- Permitting and inspections: Follow each permit from application to approval, and schedule and log inspections from the field.
- Code enforcement: Track violations and cases by location.
- Public works: Assign, track and close work orders on the map, and monitor asset condition.
- Public access: Residents, builders and developers can research parcels, analyze zoning, submit concept proposals and questions, and follow development activity.
MuniSync.ai adds chat and voice assistance on the same Esri-supported GIS data. Users can get parcel summary reports, check allowed land uses and ask about the development potential of a site within city limits.
ViewPro is an Esri Partner Network member with the State & Local Government Specialty, and its team comes from city planning. ViewPro also helped the City of Burkburnett, Texas, modernize work order management with ArcGIS.
Book a demo to see MuniSync with your own city's data.
Frequently asked questions
What is an ERP permitting module?
It is a permitting or licensing add-on within an enterprise resource planning system, the software many governments use for finance, payroll and purchasing.
Is an ERP permitting module ever the right choice?
Yes. It can suit a city with simple permit types, modest volume and little coordination between departments. The ten-application audit will show whether your city fits that description.
Do we have to replace our ERP to use community development software?
Not usually. The ERP can keep handling finance, payroll and purchasing, while a dedicated platform manages planning, permits, inspections and code cases.
What is GIS-based permitting software?
It is permitting software that ties each application, inspection and related record to a location on the city's GIS. Staff can see zoning, prior permits and open cases for a parcel at once.
Won't a second system create another silo?
It can, if the two systems aren't connected. Before you buy, confirm exactly what moves between them, how often, and who owns the connection.
Why does this matter for smaller cities?
In a small department, a few people cover many roles. Time spent chasing records or answering routine questions comes directly out of their review and field work.
.png?width=144&name=Untitled%20design%20(2).png)
