Property Maintenance Software — Data Model | FieldCamp

How a property maintenance business runs in FieldCamp — work-order intake, recurring upkeep, and inspections across many buildings under each account.

A property maintenance company keeps other people's buildings running. The account that pays you is a property manager, an HOA board, or a facilities group, and behind that one account sit many buildings you service month after month.

FieldCamp's core records already run most of that business — the customer who pays, the Request that brings in a work order, the recurring Job, the Visits your crews drive to, and the Estimate or Invoice that bills it.

The one thing the core cannot hold on its own is the set of buildings. A single property-manager account services dozens of sites, and the customer record carries only three addresses.

So the property maintenance setup adds a Property record under each account, and leans on Requests for intake and Service Agreements for the recurring program.

Property maintenance is the service business that does the upkeep. Property management is the portfolio business that holds the leases and tenants.

They are distinct, and FieldCamp models each one. If you manage the buildings yourself, start at Property Management; if you are the vendor maintaining them for someone else, this is your page.

What the core already gives you

Most of a property maintenance business is modeled, unchanged, by the records every FieldCamp account ships with on day one.

Customers — the paying account is the property-management company, HOA, or owner, with separate property and billing addresses and per-account financial rollups already built in.
Requests — a work-order ticket from a property manager fits the Request intake exactly: it captures the issue and service address, moves through triage, schedules an inspection, and converts in one move into a Job, with win, loss, and duplicate outcomes.
Jobs — the work order itself, as a one-off repair, a multi-day turnover, or a recurring maintenance round, with priority up to urgent, crew assignment, and a draft-to-paid lifecycle.
Visits — the on-site trip, with en-route to arrived to working to done tracking, location check-in, and completion gated on a captured signature or photo.
Service Agreements — the recurring maintenance plan that defines the standing terms and surfaces them on the paperwork that bills against it.
Estimates & Invoices — quotes, bills, and payments, billed back to the account that holds the contract.

Recurring upkeep is core too. A Job set to recurring auto-generates its Visits from a monthly, quarterly, or annual pattern, so a preventive round schedules itself.

Inspections, make-ready checklists, and turnover walkthroughs are best built as job forms — a form attaches to the Job, captures readings and a signature on site, and renders right on the work order. The property maintenance setup does not reinvent any of that.

It gives the work a building to point at.

What property maintenance adds

The specialized layer is one record: a Property (or Site) that sits under the account. It is its own record because a single property-manager account holds many buildings, and the customer's three address fields cannot model that.

A Property belongs to a Customer, gathers the Jobs done at that site, and rolls up the Visits performed through those jobs. Residential accounts with a single building use it lightly, or skip it; multi-building accounts use it fully.

Field	What it holds
Property name	A label for the building — for example "Maple Court Apartments" or "Tower 7 — Lobby".
Site address	The structured service address with directions for the crew.
Property type	Residential, commercial, HOA, mixed-use, or industrial.
Square footage	Building size, for sizing service and routing.
Units / floors	The count of units or floors, where it shapes the work.
Access notes	Gate codes, lockbox location, key handling, and building-engineer contact.
Service frequency	Monthly, quarterly, semiannual, annual, or as-needed.
Site photos	Reference photos and a site or floor map.
Account	The Customer this building belongs to.
Agreement	The Service Agreement that covers the recurring program at this site.

A Property page is arranged from building blocks: a header, the field group above, the address with a map pin and directions, an access brief, the related table of Jobs at this site, its service history, and a gallery of site photos.

A Property carries a light status — active, on hold, or inactive — rather than a full workflow. For most teams a Property is a reference record the work points at, so a simple status is enough.

The core records reach into this layer through a few added links. A Job gains a link to the Property it is performed at, so dispatch and service history are pinned to the exact building.

A Request gains a link to the Property and an issue category, so a ticket carries that targeting all the way through to the Job it converts into.

How these records link together

One property-manager account fans out to many Properties, each carrying its own Jobs and Visits, while the Service Agreement defines the recurring program across the sites it covers.

The work-order flow

A maintenance company runs two kinds of work: tickets that come in from the property manager, and the recurring rounds the contract schedules on its own. Both end up as a Job pinned to a Property, and both close back on the invoice.

A ticket enters through a Request, gets triaged and scheduled, and converts into a Job that carries the Property and issue across. A recurring round enters through the Service Agreement, which spawns the recurring Job directly.

From there both paths are the same: the Job dispatches its Visits, the crew works on site against the access notes and signs off, and once every Visit is done the Job is ready to bill the account.

A property manager raises a ticket — a leak in Suite 210, a failed light in the lobby. It lands as a Request against the account, tagged to the Property.

The Request is triaged and converts into a Job, carrying the Property, the issue, and the address across.

The Job dispatches one or more Visits. The crew sees the gate code and key location, works the site, and signs off.

With every Visit complete, the Job is invoiced back to the property-manager account, with the work pinned to the exact building for the service history.

Residential vs commercial portfolios

The same Property record serves both sides of a maintenance book. What changes is how heavily it is used and how completion is gated, not the underlying model.

Residential portfolios

Single-family rentals, duplexes, and small multi-family buildings, often one or a few per owner. The Property record can stay light — the customer's property address covers a single-building account. Tickets are reactive repairs and seasonal turnovers, scheduled with Service Areas and the dispatcher. Because the tenant is often absent, the signature on a completed Visit can be turned off.

Commercial portfolios

Office towers, retail centers, and HOA campuses, where one property manager holds dozens of buildings under a single account. The Property record is essential, and access runs through the building engineer. Maintenance is dense and regulatory — HVAC rounds, elevator checks, fire-system tests — so the Service Agreement governs the program and a building-engineer sign-off plus a photo can be required as evidence on every completed Visit.

The switch between the two is the property type field and the guardrails on the Job's completion step — one Visit workflow, configured per account, not a separate setup.

That is what lets the same model run from a single-truck operator servicing a few rentals to a multi-location crew holding a commercial portfolio.

Built for any size. A one-truck operator maintaining a handful of rentals runs on the core records as-is. A regional company holding HOA and commercial contracts adds the Property layer and leans on Service Agreements — on the same backbone, no rebuild.

Built on the customization engine

Every record on this page is built with the same tools every FieldCamp account has.

The Property is a custom object with its own fields and links; its active, on-hold, and inactive states are stages and workflows you can rename and reorder; and the record page — the access notes, the map pin, the related Jobs table — is assembled from record layouts.

You can also add maintenance fields directly to the core records without a new object: an issue category and target Property on a Request, a trade type on a Job, or a residential-or-commercial marker on a Customer for routing and reporting.

The portfolio of buildings is the starting point for a property maintenance account, and like everything in FieldCamp it is yours to extend.

Coming from Property Meld

Many maintenance teams coordinate work for property managers through Property Meld, where a request is a Meld and the buildings, vendors, and invoices hang off it. Almost all of that structure has a home in FieldCamp.

The shift is that here you own and shape the model, instead of working inside a fixed one.

In Property Meld	In FieldCamp	Notes
Property management company / owner	Customers	The account that pays you, with separate property and billing addresses on one record.
Property / unit	A Property — as a custom object under the customer	One account holds many buildings; model each site as its own record rather than an address field.
Meld (maintenance request)	Requests	The inbound ticket — triaged, scheduled, and converted in one move.
Meld (the work itself)	Jobs	The work order the Request converts into, pinned to the Property.
Recurring Meld	Service Agreements	The standing program that schedules the next recurring Job on a monthly, quarterly, or annual pattern.
Scheduled visit	Visits	Each trip on a job, with en-route, on-site, and sign-off.
Technician	Team Members	In-house crew, carrying skills and service areas.
Vendor	A Team Member or a vendor custom object	Third-party trades, modeled as people you assign or as their own record.
Invoice	Estimates & Invoices	Bills with line items, billed back to the account that holds the contract.
Category / tags	Custom fields	An issue category or trade type added to a Request or Job.

What you gain. In Property Meld the structure is set for you — the Meld, the property feed, and the way they relate are fixed.

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

One honest difference. Property Meld is built around a resident-facing portal, where the tenant submits the request, follows it live, and rates the work, and it pulls the property and unit feed straight from a property-management system like AppFolio.

FieldCamp is built for the vendor coordinating the work, so the account is the property manager rather than the tenant, intake runs through Requests and online booking, and the building list is a Property record you hold rather than a synced feed.

If tenant self-service and live status updates are central to how you run, plan that part of the move deliberately.