General Contractor Software — Data Model | FieldCamp

A general contractor does not run a service call. A GC runs a project — a build that moves through phases, draws on a roster of subcontractors, absorbs change orders, and is gated by permits and inspections from the city.

FieldCamp models that. Your Customers, Requests, Estimates & Invoices, Jobs, and Visits already carry the client, the bid, the field schedule, and the billing.

On top of that, a general contracting setup adds the records a build needs and core has no home for: a Project that runs the whole job, change orders, a subcontractor roster, and permits.

What the core already gives you

Most of a GC workflow is already wired into the core records. Keep them as-is and add the project layer on top.

• The client book — a Customer carries a separate property address and billing address, the lead source, and the account history, so owners, builders, and repeat developers live in one place.
• The bid front end — a Request captures the inquiry and the site walk, then converts into an Estimate. A GC bid is usually a multi-option proposal: the Good / Better / Best scope is one estimate with selectable options, plus a deposit and an approval step.
• Billing — an Invoice handles deposits, payment terms, purchase-order numbers, overdue reminders, and card or online payment.
• The field schedule — a Job is the scheduled work, carried out as one or more Visits. A multi-day phase is one visit per day, each with crew assignment, on-site check-in and check-out, and a signature-gated finish step.
• On-site data capture — pre-construction checklists, photo-required inspection sign-offs, a safety walk, and a closeout punch list are captured as job forms, not loose fields.
• The price book — materials, labor rates, and subcontracted scopes live in the price book with vendors and cost ladders, and feed every estimate, invoice, and change order.

So the project layer is additive. Core handles the client, the bid, the billing, the field schedule, and the forms; the specialized objects handle the project, the change orders, the subcontractors, and the permits.

What general contracting adds

Each item below is a custom object built on FieldCamp's customization engine — its own fields, its own links to the core records, its own stages where it needs them, and its own record page assembled from building blocks.

Together they capture the three things that define the GC business: a long-running project spine, a paper trail of scope changes, and a roster of trades doing the work.

Project — the build spine

The Project is the record that runs a build from a signed contract through closeout.

It exists because a core Job models one scheduled work order, while a build is a multi-phase job with its own long lifecycle, its own contract value, and its own percent-complete.

It carries the project name, type (residential or commercial), work type (new construction, remodel, addition, or tenant improvement), the site address, the contract value and signed date, the start and target-complete dates, a percent-complete figure, the permit-required flag, project photos and documents, and notes.

It links to the rest of the model: to the Customer it belongs to, to the Estimate and Invoice that handle the bid and billing, to the Jobs that produce the visits and crews, to its Change Orders, its Permits, and the Subcontractors on the roster, and to the team member running as project manager.

A percent-complete field can be a formula — for example, the value billed to date over the contract value plus approved change orders — so the figure updates itself rather than being retyped.

Change Order — the scope-change record

A Change Order is a single amendment to the contract: added scope, a credit, or a schedule shift, priced and approved on its own before it folds into the contract value.

It is its own record because each change carries a number, a description, a cost impact, a schedule impact, an approval state, and the signed authorization — too structured to bury on the project, and too consequential to leave as a note.

A Change Order belongs to its Project, and on approval it converts into an Estimate so the added scope is quoted and billed through the standard money model.

Its record page shows a status banner, the cost and schedule impact, a breadcrumb to its Project, the signed authorization, and the linked Estimate once the change is sold.

Subcontractor — the trade on the roster

A Subcontractor is one trade partner the GC hires — electrical, plumbing, framing, drywall, HVAC. It is a standalone record so a sub's license, insurance, and contact details follow the company across every project, not retyped per job.

A Subcontractor links to the Projects it works on and the Jobs it staffs. Its page can use a compliance block that counts down to the insurance-expiry date, so a sub whose coverage is about to lapse surfaces before they set foot on site.

Permit — the authorization with its own clock

A Permit is the city or county authorization a build depends on. It runs on the authority's clock, not yours — a phase can be underway while its permit is still applied-for — so it gets its own lifecycle, separate from the project's.

Permits are a full example in their own right. The Permits data model covers the permit number, issuing authority, fees, dates, and the applied-to-closed lifecycle in detail.

On a GC project, a Permit parents to the Job or the Project the way Equipment parents to a customer, and one build can carry several at once — building, electrical, plumbing, and mechanical.

How the GC objects link to the core

A Customer owns Projects. Each Project pulls in the core bid and billing records, the Jobs that produce its visits and crews, its change orders and permits, and the subcontractors staffing the work — with a team member as project manager.

The project lifecycle

A Project moves through a named build lifecycle — far longer than a service call. The diagram shows the phases a GC project runs through, from the bid to closeout.

A few of these stages carry requirements before a project can move on. Marking a project Contract Signed asks for the contract value and signed date and shows a confirmation.

Moving into Closeout can ask for the punch-list sign-off, and on residential work, an owner signature.

Along the way, the project keeps itself in sync. Marking it Contract Signed spins up the first install Job. Reaching Permitting, Punchlist, or Closeout sends a notification to the office, the project manager, or the owner.

The phase names are yours to rename. A remodeler might run Demo, Rough, Finish; a commercial builder might run Sitework, Structure, Envelope, Interiors — the same pipeline, relabeled to the way the shop talks about its work.

Residential vs commercial

One model serves both. The differences are a handful of fields and stages that turn on or off per segment — not a separate build.

The Project, Change Order, and Subcontractor records serve both — fill the fields each segment needs. The permit-heavy, retainage-driven commercial path and the selection-heavy residential path are the same objects, configured differently.

Built on the customization engine

None of these records are a separate product bolted on.

The Project, Change Order, and Subcontractor are custom objects with their own fields; the build lifecycle and the change-order approval steps are stages and workflows with their own requirements and automations; and each record page is arranged from building blocks like the project board, the cost view, and the compliance countdown.

Permits are the Permits custom object parented to the build.

Rename a stage, add a field, or rearrange a page, and the model bends to how your shop actually runs — without touching the transaction spine underneath.

Coming from JobTread

Most GCs on JobTread can bring their structure into FieldCamp directly — the contacts, the jobs, the budgets and cost items, the schedules, the change orders, the subs, and the daily logs all have a home here.

The difference is that in FieldCamp you own and shape the model, rather than fitting your shop to a fixed one. (The same mapping holds if you are moving from Buildertrend — the entity names differ, the shapes line up.)

What you gain. In JobTread the structure is fixed — the objects, their fields, and how they relate are set for you.

In FieldCamp every one of those records is yours to rename, extend, restage, and relayout, so you can match your old setup first and then go past it with custom objects and fields and your own stages and workflows.

One honest difference. JobTread ships deep progress-billing and budget tooling — AIA G702 / G703 payment applications, a schedule of values, and live budget-versus-actual tracking down to the cost item.

FieldCamp models the project's cost view as estimated against actual and bills a build as a sequence of progress invoices, but the formal schedule of values, automatic retainage withholding and release, and AIA form output sit outside the core invoice model, as noted above.

If draw-schedule billing and cost-item-level budget tracking are central to how you run a job, plan that part of the move deliberately.

Related records

See also

More in the FieldCamp data model.