Remodeling Software — Data Model | FieldCamp

A remodeler does not build on an empty lot. The work happens inside an occupied home — a kitchen the family still cooks in, a bath that has to come back online — and it lives or dies on the finishes the homeowner picks.

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

On top of that, a remodeling setup adds the records a renovation needs and core has no home for: a Project that runs the whole job through its phases, a Selection record for every finish the client chooses against an allowance, change orders, and a subcontractor roster.

This is the occupied-home, finish-driven cousin of the general contracting setup and the construction setup — same project layer, with selections and allowances pulled to the front.

What the core already gives you

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

• The homeowner book — a Customer carries a separate property address and billing address, the lead source, and the account history, so repeat clients and referral homeowners live in one place.
• The bid front end — a Request captures the inquiry and the in-home consultation, then converts into an Estimate. A remodel 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 the deposit, payment terms, 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 — a pre-demo walk, photo-required progress sign-offs, a moisture or asbestos check before demo, 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 homeowner, the bid, the billing, the field schedule, and the forms; the specialized objects handle the project, the selections and allowances, the change orders, and the subcontractors.

What remodeling 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 what defines the remodeling business: a phased project inside a lived-in home, a finish chosen and reconciled against a budget on every line, a paper trail of scope changes, and the trades doing the work.

Project — the remodel spine

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

It exists because a core Job models one scheduled work order, while a remodel 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 (kitchen, bath, whole-home, addition, or basement), the site address, the contract value and signed date, the start and target-complete dates, a percent-complete figure, 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 Selections and Change Orders, to 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.

Selection & Allowance — the finish the client picks

This is the record that defines remodeling. On a renovation, much of the contract value is not finishes the remodeler chose — it is finishes the homeowner will choose later: the cabinets, the countertop, the tile, the faucet, the flooring.

Each is budgeted as an allowance in the contract, and each gets a real selection once the client picks at the showroom.

A Selection is a child object under the Project, so one project gathers an ordered list of every finish decision from design through install.

It earns its own record because each pick carries a category, a budgeted allowance, the chosen product and its real price, a deadline that gates the schedule, a photo, an approval state, and — the part that defines remodeling — a variance against the allowance that the homeowner either pays as an overage or receives as a credit.

Because the variance is a formula, the over-or-under figure recomputes itself the moment a price is entered — no spreadsheet, no retyped math.

A selection that lands over its allowance is, in remodeling terms, a scope change the client has to pay for, so on approval it can convert into a Change Order through an automation, folding the overage into the contract value the same way any other added scope does.

Change Order — the scope-change record

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

On a remodel, change orders are frequent — concealed conditions behind a wall and homeowner upgrades both land here.

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, and the signed authorization.

Subcontractor — the trade on the roster

A Subcontractor is one trade partner the remodeler hires — electrical, plumbing, tile, cabinetry, 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 in an occupied home.

How the remodeling 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 selections and change orders, and the subcontractors staffing the work — with a team member as project manager.

An over-allowance selection flows into a change order, which is quoted as an estimate.

The remodel lifecycle

A Project moves through a named remodel lifecycle — far longer than a service call. The diagram shows the phases a renovation runs through, from the design phase to closeout.

The design phase comes first because a remodel sells the plan before it sells the build, and the Selections phase has its own slot because finishes have to be locked before demo starts.

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 Demolition can ask that every selection on the critical path is approved, and moving into Closeout can ask for the punch-list sign-off and an owner signature.

Along the way, the project keeps itself in sync. Marking it Contract Signed spins up the first Job and the project's allowance Selections. Reaching Selections, Punchlist, or Closeout sends a notification to the office, the project manager, or the homeowner.

The phase names are yours to rename. A kitchen-and-bath shop might run Design, Selections, Demo, Rough, Finish; a whole-home remodeler might add a Structural phase — the same pipeline, relabeled to the way the shop talks about its work.

Built on the customization engine

None of these records are a separate product bolted on.

The Project, Selection, Change Order, and Subcontractor are custom objects with their own fields; the remodel lifecycle, the selection approval steps, and the change-order workflow are stages and workflows with their own requirements and automations — including the rule that turns an over-allowance selection into a change order; and each record page is arranged from building blocks like the project board, the cost view, the allowance-variance metric, the compliance countdown, and the finish photo gallery.

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.

Related records

Coming from Buildertrend

Many remodelers run on Buildertrend, where a renovation is organized around a job with selections, allowances, change orders, a schedule, and a client portal. That structure maps onto FieldCamp cleanly — the same pieces, with you in charge of how they fit.

The difference is that in FieldCamp the model is yours to shape.

A selection is a real record with its own fields, deadline, and approval state, not a row inside a fixed template, so you can match how your shop sells finishes and then go past it.

What you gain. In Buildertrend the renovation structure is set for you — the objects, their fields, and how they connect are fixed. In FieldCamp the Project, Selection, Change Order, and Subcontractor are custom objects and fields you own, and the remodel phases are stages and workflows you name and guard. Match your current setup first, then rename a phase, add a field to a selection, or rearrange a record page without touching the transaction spine underneath.

One honest difference. Buildertrend ships a built-in draw and progress-billing engine with a schedule of values tied to phase milestones.

FieldCamp handles the deposit, payment terms, and partial payments, so you bill a project as a sequence of progress invoices — one per phase — but a formal draw schedule, automatic retainage withholding and release, and a schedule of values live outside this model.

If draw-based billing is central to how you run, plan that part of the move deliberately. The client portal experience also differs: FieldCamp surfaces selections, approvals, and invoices to the homeowner through its own records rather than a single Buildertrend-style portal.

See also

More in the FieldCamp data model.