FieldCampPermits — Custom Object Example | FieldCamp
Track the permits a job depends on as a custom object in FieldCamp — permit number, authority, fees, and an applied-to-closed lifecycle attached to a job.
A Permit record is the city or county authorization a job depends on — the paper an electrical, plumbing, solar, or construction crew has to pull before some work can legally start, and close out before the work is done.
It is a clean example of a custom object: a record type you add to FieldCamp to track something your trade lives by but the standard records do not carry.
Each Permit attaches to the Job it authorizes and holds the permit's own number, fees, dates, and status.
The reason a permit earns its own record is timing.
A permit runs on the authority's clock, not yours — a job can be in progress while its permit is still applied-for and waiting on the city — so it needs its own lifecycle, separate from the job's.
What a Permit captures
A Permit record holds the facts you would otherwise hunt for across email and the city portal: the number, who issued it, what kind it is, what it cost, and the dates that govern it.
The table below maps each field to the field type it is built from.
| Field | Field type | What it holds |
|---|---|---|
| Permit number | Text | The number issued by the authority, used on every inspection and the closeout card. |
| Issuing authority | Text | The city, county, or building department that granted the permit — the authority having jurisdiction. |
| Permit type | Single choice | The kind of permit: electrical, service upgrade, solar, EV charger, generator, plumbing, building, or low-voltage. |
| Permit fee | Currency | What the permit cost to pull, so it can roll into job cost. |
| Application date | Date | When you submitted the application. |
| Approved date | Date | When the authority issued or approved the permit. |
| Inspection date | Date | The scheduled or completed inspection date the work is gated on. |
| Expiration date | Date | When the permit lapses if work is not finished and closed. |
| Posted on site | Checkbox | Whether the permit is physically posted at the job site, as many jurisdictions require. |
| Permit document | File | The scanned permit, plan-set approval, or signed closeout card. |
The owner and the address come from the records the Permit hangs off, not from fields retyped onto the permit itself. Because each Permit belongs to a Job, it inherits that job's Customer and site address automatically.
Mark Permit number and Approved date as required on the move into Approved. A permit cannot reach Approved without the number that every later inspection refers to, so the data is clean the moment it matters.
How Permits connect
A Permit sits under the Job it authorizes, and through that Job it rolls up to a Customer.
One Job can pull more than one Permit — a commercial build might carry a building, an electrical, and a plumbing permit at once — while each Permit belongs to exactly one Job.
Read the diagram outward from the Permit:
- A Permit belongs to exactly one Job — the work order it authorizes. A residential service job often has none or one; a commercial job can carry several at once.
- A Job belongs to exactly one Customer, so every Permit rolls up to a real customer and a real site without anyone re-entering either.
Because the Permit is a child of its Job, opening the job shows its permits in one place, and opening a permit shows a link straight back up to the job, the customer, and the address.
The permit lifecycle
A Permit moves through its own stages as a custom pipeline — a sequence that mirrors how the authority actually drives the paperwork, independent of the job's own stages.
A new permit starts at Applied and waits on the authority. Once granted it becomes Approved, the inspection is scheduled, and the result either passes or fails.
A failed inspection loops back for a re-inspection; a passed final lets the permit close. If the authority turns the application down, the permit branches to Rejected and can be revised and resubmitted.
The move into Approved is the natural place for a guardrail. Require the Permit number before the move from Applied to Approved is allowed, so no permit advances without the number every later step refers to.
The move into Failed can require correction notes, and the move into Closed can require the signed-off closeout document, so each finished permit carries its own proof.
One honest limit on reminders. A stage change can trigger a follow-up — moving a permit to Approved can notify the project lead, and a failed inspection can fire a notification — because those run off the automation that fires when a stage changes.
What a stage change cannot do is watch a date.
A reminder timed to fire a set number of days before the Expiration date is not a stage-change automation; that kind of time-based deadline alert lives in FieldCamp's separate workflow automation tools, not on the permit pipeline itself.
How it is built in FieldCamp
Permits is a custom object parented to the Job — the same way Equipment is built as an asset that belongs to a customer.
You define the fields above, attach the custom workflow so each permit moves Applied through Closed, and the object gets its own place in navigation and its own record page.
That record page is assembled from the same building blocks as every other record: a status header, a field group for the permit's facts, a breadcrumb back to the parent Job, a files block for the scanned permit, and a timeline.
You can reorder, add, or hide those sections to match how your office reads a permit — see record layouts.
None of it is special-cased.
The permit lifecycle, the required-field guardrails, and the link up to the Job are all assembled from primitives any account can use, so an electrical shop, a solar installer, and a general contractor each build the version of Permits their jurisdiction demands.
See also
How to create your own record types and the fields they carry.
Give a custom object its own stages and guardrails, like the permit lifecycle above.
Arrange the blocks on the Permit record page to match how your office works.
The work order a Permit attaches to, and through it the customer and the site.
See Permits in a full trade model, alongside inspections, assets, and projects.
How the core records connect, and how to make them your own.
Bait Stations — Custom Object Example | FieldCamp
Model bait stations as a custom object in FieldCamp — station number, placement, bait type, condition, and last-checked status, sitting under a property and checked each visit.
Warranties — Custom Object Example | FieldCamp
Track warranties as a custom object in FieldCamp — provider, coverage type, dates, terms, and claim status linked to the equipment a warranty protects.