Esri ArcGIS Parcel Layers, Digital Plan Review Markup, Inspector Mobile Routing and Online Fee Payment Integration for a Custom US Permitting Platform

This article is part of our series on Custom Municipal Permitting and Code Enforcement Platform Development for US Cities and Counties: Building a Plan Review, Inspection, and Citizen Portal System

Introduction: One of These Is Upstream of Everything Else

Three of the four connections here are conventional integrations. One is a data authority question that decides whether records stay usable in ten years. 

Parcel and address data come from a system the platform does not own. A platform that drifts from that authoritative record produces history that nobody can later match to the property. That defeats the purpose of keeping it. 

That data relationship is foundational to custom municipal permitting platform development because every later workflow depends on reliable property identity. Custom software development must preserve that link as parcel records, addresses, and jurisdictional data change. 

The other three permitting software integrations are more familiar: plan markup, inspector routing, and payment. Plan markup already has established tools across design and construction. Inspector routing is a field problem with an offline requirement. Government payment processing must also account for public-sector controls, fees, and reconciliation. 

On the public side, web application development supports document submission, fee payment, status tracking, and applicant responses.

Esri ArcGIS Parcel Layers

The Authority Question First

Establish who owns the authoritative parcel and address record. It is almost always the jurisdiction’s GIS address authority or the assessor. That authority operates under a process that the permitting department does not control. The permitting platform consumes that record and should not create addresses.

Where an applicant reports an address missing from the authoritative source, that is a referral to the address authority. It is not a new record.

What the Integration Carries

A solid Esri ArcGIS parcel integration carries parcel geometry and identifiers, addresses with their status, and ownership from the assessor. Zoning designation and overlay layers matter too: floodplain, historic district, environmental constraint, and utility service area. 

Most jurisdictions expose these as map and feature services from an enterprise GIS platform, and consuming them is well established. Confirm what is published, at what refresh cadence, and under what licensing.

Parcels Change, and the History Must Survive

Splits, combinations, annexations, and address changes all happen. A permit issued against a parcel that no longer exists in that form still has to be findable. It should trace back to the land it relates to.

Design the relationship so history follows the land, not the identifier. This is the part most often handled badly, and the part that matters most a decade later.

Digital Plan Review Markup

Plan review markup is a specialized tool. The honest position is that a custom platform should integrate one rather than build it.

The requirements are substantial. Reviewers need to render large drawing sets responsively, mark up the same set with attribution, and use measurement and takeoff tools. Digital plan review markup also depends on comparing submittal versions, so a reviewer sees what changed. Established tools in design and construction already do this well.

Architects and engineers submitting plans already know them, which matters. A reviewer’s markup that an applicant cannot open is a real problem.

What the permitting platform owns is the workflow around it. That means routing the set to reviewers and collecting comments into a consolidated letter with code citations. It also means tracking resolution across cycles and holding the approved set as the record.

Two specifics deserve design attention. Version comparison is the single feature that most reduces resubmittal review time. It depends on the platform keeping submittal versions properly, rather than overwriting them.

Architect and engineer stamps on submitted plans are governed by state licensing board rules. Those rules set their own requirements for digital signatures and seals. Confirm what your state’s boards require before designing a paperless submittal, since this is a common late discovery. The approved set becomes a permanent record.

Inspector Mobile Routing

The inspector application is the second-largest engineering component after the review workflow. Its defining constraint is connectivity.

Offline must be the architecture, not a fallback. An inspector works in basements, crawlspaces, steel-framed structures, and rural areas where the signal is unreliable. A day’s results lost to a sync failure means a day of inspections repeated.

That calls for local storage of the day’s assignments. Offline field data capture needs to work fully disconnected, with sync that resumes rather than restarts.

Routing runs on the day’s assignments and geography. Ideally, a supervisor can reassign as requests arrive, and an inspector can reorder based on site knowledge.

Capture needs to be fast: checklists by inspection type and results, with the provision cited on a failure. Photographs get attached to specific items, with a signature where the jurisdiction collects one. Getting inspector mobile routing right usually means treating custom mobile app development as core infrastructure, not an afterthought.

Reference material should stay available offline: the approved plan set, conditions of approval, prior inspection history, and the code sections. That is what lets an inspector resolve a question on site, rather than returning. Immediate result communication to the contractor follows once connectivity returns.

Online Fee Payment

Payment in government carries constraints that commercial payment does not, and they shape the integration rather than sitting alongside it.

The processor question comes first. Public agencies frequently use processors serving the government sector. Statewide or cooperative arrangements that the jurisdiction already participates in are common. Using an existing arrangement is usually faster than procuring a new one.

Convenience fees are the constraint most likely to surprise a development team. Whether a jurisdiction may pass card processing costs to the payer is governed by state law. The adopted fee schedule also plays a role. How that must be disclosed is governed, too.

Some jurisdictions absorb the cost; some cannot. Establish the position before designing the checkout.

Cash and check remain necessary, since a meaningful share of applicants pay in person. The system must handle counter payments, reconciliation and deposits alongside online transactions. Refunds happen too: an application withdrawn, a fee charged in error, a valuation revised. Refund workflow in government carries approval requirements.

Reconciliation to the jurisdiction’s financial system, with revenue coded to the correct account, is where finance judges the platform. That applies to any online permit fee payment system. Payment card obligations apply here as they would anywhere.

Supporting Connections

The jurisdiction’s financial system handles revenue posting and, where relevant, accounts receivable on abatement cost recovery. Contractor licensing verification checks against state or local license data. Records management and archival systems matter where the jurisdiction operates one, since retention may be administered centrally.

Agenda and meeting management serves land use applications going to a commission or board. Notification runs by email, text, and physical mail, with proof of delivery where notice carries legal requirements. Identity and single sign-on for staff align with the jurisdiction’s directory. Utility and public works systems matter where a permit triggers a service connection or a right-of-way action.

Each carries onboarding within a public sector environment. Confirm terms and security review requirements before designing around them.

Reconciliation and Failure Handling

Each connection fails quietly, and in a public record environment, some failures become disclosure problems.

A parcel refresh that did not run leaves stale geometry. A field session that never synced loses a day’s work. A payment not posted to the financial system creates a gap. A notice never mailed breaks the record.

An approved plan set not retained as the record is another. Each needs a queue with an age and an owner.

Two checks earn their place immediately. A daily reconciliation of payments against revenue posted matters. Unposted revenue in a public agency is a financial problem with an audit attached.

A second check confirms every issued permit has its approved plan set and conditions retained. That record’s absence surfaces years later when someone asks what was approved.

Sequencing These Connections Right

Agencies that settle the parcel authority before designing end up with records that stay usable. Agencies that integrate established markup tooling rather than building it save real engineering time. Treating offline as the field application’s architecture and settling the payment position before the checkout rounds out the list.

If parcel records and plan review are why you are considering a custom platform, settle the GIS authority relationship first. That decision is what the rest of the architecture depends on. NewAgeSysIT helps agencies define these dependencies and sequence the technical decisions before development begins. Learn more about digital transformation solutions from one of the leading AI software companies in the United States.