The Problem with Permitting in Field Operations

Every infrastructure project of any complexity requires permits. A construction permit from the municipality, an excavation permit from the utility, an environmental clearance, a road occupancy permit, sometimes all four for the same stretch of road. The permit is not optional — work cannot legally begin until the permit is in hand, and the inspector who shows up afterward wants to see documentation that proves it was.

The problem is not the permit itself. The problem is where it lives in your workflow. In most organizations, the answer is: somewhere else. A spreadsheet that someone updates weekly. A shared drive folder that nobody can find when the inspector asks. A separate permitting application that the field team does not use because it is not where they do their actual work. The permit becomes a side process that runs in parallel to the real work, connected to it only by memory and good intentions.

This is how permits get missed, expire without anyone noticing, or arrive after work has already started. Not because anyone was negligent, but because the permit lived in a different system from the work it was supposed to gate.

Where Parallel Workflows Break Down

The usual response to this problem takes one of three forms.

A spreadsheet or shared document. Someone maintains a permit tracker — a row per permit, columns for status, expiry date, and responsible person. This works for a small project. It stops working the moment more than one person needs to update it, the moment permits span multiple projects, or the moment someone asks for a reliable history of who changed what and when. Spreadsheets do not have audit trails. They do not send notifications when a date is approaching. They do not prevent someone from accidentally deleting a row.

A dedicated permitting application. Purpose-built software that tracks permit applications, approvals, conditions, and expiry dates. These exist, and they solve the tracking problem. What they do not solve is the integration problem. The permit lives in one system. The work order lives in another. The field crew uses a third. Now you have three places to check, three things to keep in sync, and a gap between them where mistakes happen. Did someone start work before the permit cleared? The permitting system does not know, because it cannot see the work order status. Did the permit expire while work was in progress? The work management system does not know, because it cannot see the permit status.

Email and verbal confirmation. Someone emails the crew lead to say the permit came through. The crew lead tells the team. Nobody records the timestamp. When the inspector asks for documentation, the project manager searches their inbox. This is not a system. It is an absence of one.

Each of these approaches creates the same structural weakness: the permit and the work it governs live in different places, maintained by different people, with no automatic link between them. The moment one side changes, the other side is out of date until someone remembers to update it.

Permits as Work Items

Our approach is straightforward: a permit is a work item. It gets planned under a task, tracked as a work order, documented through reports, and validated through the same quality control chain as every other piece of field work.

A task represents a unit of planned work — "Install fibre on Oak Street." Under that task, there might be three work orders: one for obtaining the construction permit, one for the physical installation, and one for the post-installation inspection. The permit work order sits alongside the construction work order in the same task, visible in the same project view, tracked by the same progress system.

The permit work order carries its own metadata as structured properties — permit number, issuing authority, expiry date, conditions, application reference. These are not buried in a description field. They are searchable, filterable fields on the work order, available in exports and reports.

The permit has a due date and notifications. When the expiry date is approaching, the system sends the same notifications it sends for any other due date — batched digests, in-app badges, calendar feed. No separate alerting system to configure.

The permit goes through the same validation chain. When the permit is obtained, a report is submitted with the permit document attached. A validator confirms it is the right permit, for the right location, with the right dates. If the permit has conditions, the validator records them as findings. The validation status — pass, fail, needs revision — controls whether the downstream work orders can proceed.

The permit's status is visible in the project rollup. A project manager looking at the task sees the permit work order at "completed" or "pending" alongside the construction work orders. There is no need to cross-reference a separate system. If the permit is not done, the task is not done, and that is visible to everyone at a glance.

What About Municipal Systems?

An honest question that comes up in every permitting conversation: should the software integrate directly with municipal permitting portals?

We looked at this carefully and decided not to build it. The reason is simple: there is no standard. Every municipality runs a different portal — different forms, different workflows, different APIs if they have APIs at all. Many still operate on paper. Building an integration with one municipality helps one municipality's users and nobody else. Building a generic "permitting integration" that claims to work everywhere is a promise that cannot be kept.

What actually happens in practice is that a person logs into the municipal portal, checks the permit status, and enters the relevant dates and reference numbers into the work order. The system's job at that point is to track the date, notify when it is approaching, and produce a reliable audit trail when someone asks for it later. That is not a gap. It is a realistic acknowledgment of where the boundary sits between your internal system and external government processes.

The Audit Trail That Inspectors Actually Want

When a regulatory inspector or a client auditor asks about permitting, they are asking three questions: Did you have the permit before work started? Was the permit valid for the location and scope of work? Can you prove it?

When the permit is a work order in the same system as the construction work, the answers are structural rather than assembled after the fact:

The permit work order has an immutable timeline — created date, completion date, validation date — that can be compared against the construction work order's start date. If work started before the permit was validated, the dates show it.
The permit report includes the attached permit document, the validator's confirmation, and any conditions recorded as findings. The report becomes read-only after validation, so the evidence cannot be altered.
The inventory transactions on the construction work orders are timestamped and immutable. If materials were picked up before the permit cleared, the QR pickup transaction timestamps show it.
Everything is exportable — CSV, PDF, audit log — from a single system, in a single query. No cross-referencing between separate databases.

The inspector does not care which module produced the documentation. They care that it is consistent, timestamped, and tamper-evident. When the permit and the work share a system, that consistency is automatic. When they live in separate systems, it has to be manufactured.

Summary

Permitting is a universal requirement in infrastructure field work, and the most common failure mode is not missing a permit — it is tracking the permit in a system that is disconnected from the work it governs.
Spreadsheets, dedicated permitting software, and email-based confirmation all create the same structural weakness: the permit and the work live in different places with no automatic link between them.
Treating a permit as a work order in the main workflow means it inherits the same planning, tracking, validation, and audit trail infrastructure as every other work item — no parallel process to maintain.
Permit-specific metadata — permit number, issuing authority, expiry date, conditions — lives as structured properties on the work order, searchable and filterable alongside all other work data.
Municipal permitting portal integration is a problem nobody has solved generically, because there is no standard. The realistic workflow is a human entering dates from the portal, and the system tracking and notifying from there.
The audit trail inspectors want — proof that the permit preceded the work, that it was valid for the scope, and that the documentation is tamper-evident — falls out naturally when both the permit and the work share the same immutable timeline.
No separate module to learn, no parallel workflow to maintain. Permitting is built into the main flow by design.