Custom Objects & Fields — Customize FieldCamp | FieldCamp

Add custom fields and custom objects in FieldCamp to track anything your field service business needs — standalone or nested, schedulable, with rules and relationships.

Every business tracks something the next one doesn't. A pest-control company logs bait stations.

An HVAC contractor records refrigerant types and warranty dates. A franchise needs the same permit record at every location.

FieldCamp bends to fit: on top of the core records you get on day one, you can add your own fields to any record and create entirely new record types of your own.

The foundation stays connected and working — you extend it, you never rebuild it. A single-truck operator can add one field; a multi-location franchise can model whole new parts of its business.

Same data model, tailored to you.

Custom fields

A custom field is a piece of information you want to capture that isn't there out of the box.

You add it once to a record type — Customers, Jobs, Visits, Estimates, Invoices, the Price Book, or any custom object — and from then on every record of that type has that field, ready to fill in.

Custom fields show up on the record page alongside the built-in ones, so a refrigerant type sits right next to the job address, and a warranty date next to the customer's name.

You choose a field type that matches the kind of information you're capturing. The type controls how the field looks, how data is entered, and how it's checked.

Pick the closest fit and FieldCamp handles the rest — the right input, the right keyboard on mobile, the right validation.

Field type	What it captures
Text	A line of free text — a label, reference, or short note.
Long text	A multi-line note or description.
Number	A numeric value, such as a count or a reading.
Currency	A money amount, shown with your currency symbol.
Date	A single calendar date.
Date & time	A date together with a time of day.
Dropdown (single choice)	One option chosen from a list you define.
Multi-select	Several options chosen from a list you define.
Checkbox (yes/no)	A simple on-or-off toggle.
Email	An email address, checked for a valid format.
Phone	A phone number, formatted as you type.
Website link	A web address, checked for a valid format.
Address	A full street address with city, state, postal code, and country.
Link to another record	A pointer to a related record, such as the customer who owns a piece of equipment.

The exact set of types varies a little by where you add the field — a custom object, a client profile, or a job form. Job forms add input types built for on-site work, like ratings, photo capture, and signatures.

Files attach to a record through its Files tab rather than a field, and a value worked out from other fields — or from a record's children — comes from an Auto Calculation rule, not a field type.

Field rules

Beyond its type, each field can carry a few settings that keep your data clean and your forms tidy — applied the same way every time, whether a record is filled in at a desk or on a phone in the field.

You set these when you add or edit the field. Where it sits on the page is handled in the layout.

Setting	What it does
Required	The record can't be saved until this field is filled.
Hidden	Keep a field in your data model but off the form until you need it.
Read-only	Show a value for reference without letting it be edited.
Choices	For a dropdown, the exact list of options to pick from — nothing outside the list can be entered.

A link to another record field can go further: you can narrow which records it offers based on another field's value — for example, only show units that belong to the selected property — and a link to a team member can be limited to certain roles.

A couple of checks come built in with the type and need no setup: an email or website field confirms the value is a valid address, and a phone field formats the number as it's entered.

For anything stricter than required — a value range, a length limit, an allowed list, or a required format — set up a Validation Rule, which checks the fields before a record is saved.

Only an administrator can add, edit, or remove the fields on a record type. Once a field exists, anyone on your team can fill it in. To keep records fast and clean, add only the fields you'll actually use.

Custom objects

Custom fields extend records you already have. A custom object goes further: it's an entirely new record type you create to track something the core records don't cover.

Permits, warranties, bait stations, fleet vehicles, equipment, properties, units, pools, service agreements — if your business keeps a list of it, you can make it a record type in FieldCamp, with its own fields, its own page, and its own place in the navigation.

Like the core records, a custom object can hold fields, move through stages, connect to other records, and — when it's something you service — have jobs and visits scheduled against it.

Creating a custom object

Setting one up is a short, guided flow. You name it, decide where it lives, and switch on the capabilities it needs.

Name the record type

Give it a singular and plural name (Permit / Permits), pick an icon and color for it, and choose whether it appears in the navigation sidebar.

Decide where it lives

Let it stand alone as its own record type, or nest it under a parent such as Customer or Job so each one belongs to a specific record. (More on this below.)

Turn on scheduling, if you service it

If you send technicians to work on these — properties, units, equipment, pools — make it schedulable so you can book jobs and visits against each one.

Add its fields

Build out the record with the field types and rules above — a permit number, an expiry date, an issuing authority. The permit document itself lives on the record's Files tab.

Connect it to other records

Add relationships so it links to the customers, jobs, or other objects it relates to.

Give it stages, if it needs them

If the record moves through a lifecycle, define the stages it passes through so its status stays current — for example Active → Under Maintenance → Retired.

Standalone or nested under a parent

When you create a custom object, the first real decision is where it sits in your data model. There are two shapes.

A standalone object is its own list, reached from the navigation sidebar — a fleet of vehicles you manage across every job, a catalog of properties, a register of certifications.

A nested (child) object belongs under a parent record. Each one is tied to a specific Customer, Job, or other record, and it appears right on that record's page.

Equipment owned by a customer, permits pulled for a job, units installed at a property — these are nested objects, because each one only makes sense in the context of the record it belongs to.

Rule of thumb: if you'd ask "whose is it?" or "which job is it for?", nest it under that parent. If it stands on its own and you browse the whole list, keep it standalone. You can always link a standalone object to other records with a relationship instead.

Schedulable objects

Some of the things you track aren't just records — they're things you send people out to work on, again and again. A rental unit gets turnovers. A rooftop unit gets maintenance. A pool gets a weekly visit.

Mark a custom object schedulable and you can book jobs and visits against each individual record — not just against the customer, but against the exact unit, asset, or location.

Every schedulable record gets its own Scheduled Jobs view, so you can see the full service history of that one unit or piece of equipment in one place — every visit it's ever had, and everything coming up.

When you schedule a job, that record becomes a "schedule for" target alongside your customers, so a dispatcher can send a crew to Unit 4B or Rooftop Unit #2 directly.

Property management — units

A property manager makes Units schedulable and nests them under each Property. Turnovers, repairs, and inspections are scheduled against the specific unit, so each one carries its own complete service history.

HVAC — equipment

An HVAC contractor makes Equipment schedulable under Customer. Every maintenance visit is booked against the exact rooftop unit, and the unit's record shows each service it's ever had.

Pool service — pools

A pool company makes Pools schedulable. The weekly route is built from pool records, and each pool's page lists every visit, reading, and chemical dose in order.

Scheduling is a switch you turn on per object — not every custom object needs it. A list you only reference (like certifications or vendors) stays a plain record type. Anything a technician physically works on is a good candidate to make schedulable.

Connecting objects to each other

A custom object rarely lives alone. Relationships are how it links to the rest of your data model, so records point at each other and you can move between them.

You set the kind of relationship to match how the two record types relate in real life.

Relationship	What it means	Example
Many-to-one	Many of these belong to one of those.	Many Units belong to one Property.
One-to-many	One of these has many of those.	One Property has many Units.
One-to-one	Exactly one on each side.	One Vehicle has one Telematics Device.
Many-to-many	Any number on each side.	Technicians hold many Certifications, and each certification is held by many technicians.

Nesting an object under a parent (above) is the most common relationship — it's a many-to-one tie that also shows the records right on the parent's page.

For everything else, a relationship — or a link to another record field — connects the two record types without nesting, so you can jump from an equipment record to the job it was last serviced on, or from a permit to the inspector who signed it.

What each record page can show

A custom object's page is built from the same building blocks as the core records. Beyond its own details, you can switch on extra tabs per object.

Tab	What it shows
Details	The object's own fields, arranged the way you lay them out.
Scheduled Jobs	Every job and visit booked against this record — appears when the object is schedulable.
Notes	Free-form notes your team adds over time.
Files	Documents and photos kept with the record.
Activity	A timeline of changes and events on the record.

Nested objects and relationships add their own tabs too, so a Property can show its Units, and a Customer can show its Equipment, right alongside these.

How a custom object fits the model

Here's an Equipment custom object nested under Customer, with a handful of custom fields, schedulable, and linked to the Job it was serviced on.

Read it outward from the core records: one Customer can own many pieces of Equipment, and because the equipment is schedulable, each piece can have many Jobs booked against it.

The Equipment record itself holds the fields you defined — a serial number, a type, a warranty date, a replacement cost, an install date, and a status that moves through its own stages. The manual and any photos live on its Files tab.

The Customer and Job records are untouched; the Equipment object sits alongside them and links in.

Examples

Pest control — bait stations

A single-truck pest-control operator creates a Bait Stations object nested under Customer. Each station has a location field, a bait-type dropdown, a last-serviced date, and a checkbox for whether it needs replacing. The technician updates them on site, and every station is tied to the customer it protects.

HVAC — equipment and warranties

A growing HVAC contractor adds custom fields to Jobs for refrigerant type and warranty date, then creates a schedulable Equipment object under Customer — model, serial number, and install date, with the warranty document on its Files tab — so service history follows the unit, not just the job.

Multi-location — permits

A multi-location restoration franchise creates a Permits object under Job. Each permit carries a permit number, an issuing authority, and an expiry date, with the document on its Files tab, and stages that run from Applied to Approved to Closed. Every location works the same Permits record, so the franchise sees one consistent process across all sites.

Make it your own

Custom objects and fields are one part of tailoring FieldCamp. They pair with the other ways you shape the model to your business.

Record layouts

Arrange where your custom fields appear on a record page, and build a page layout for a custom object from the same building blocks the core records use.

Stages & workflows

Give a custom object its own lifecycle, and rename, reorder, or add stages on any record so the workflow matches your process.

Automations

Set up rules so that when a record reaches a stage, FieldCamp does the next thing for you — across both core and custom records.

The data model

See how the core records connect, and how your custom objects sit alongside them in the bigger picture.

Customers

The customer record many custom objects nest under — equipment, permits, and properties belong to a customer.

Jobs

The work order. Add custom fields to a Job, or nest a custom object under it so records belong to a specific job.