Rules & Automations — FieldCamp's Rules Engine | FieldCamp

FieldCamp rules run as records are created, updated, change stage, or are deleted — validate fields, create child records, roll status up, calculate values, convert records, and more.

A record in FieldCamp doesn't just sit there. As it's created, saved, moved through a stage, or deleted, rules can run in the background and do the next thing for you.

When a job is approved, FieldCamp creates its first visit. When every visit on a job is finished, the job completes itself. When an invoice is paid, the job moves to Paid.

These are rules — in the app you'll see them as "computed rules" — and many are already running on your core records the day you sign up. You can add your own to any record type, including the custom objects you create.

The kinds of rules

FieldCamp has eight kinds of rule. Each one watches for something to happen, then takes an action without anyone clicking a button.

Rule	What it does
Validation Rule	Checks fields before a record is saved — require a field, set a minimum or maximum value, limit length, restrict to a list of allowed values, or enforce a format like email or phone.
Child Creation	Automatically creates related child records — for example, the first visit the moment a job is approved.
Status Propagation	Works a parent's status out from its children — a job moves to Completed once all its visits are done.
Auto Calculation	Works a field's value out from a record's children — a count, a total, or a rolled-up figure that updates as those children change.
Conversion Action	Turns a record into another type — a completed job into an invoice, an approved estimate into a job — carrying the customer, line items, and totals across.
Visit Phase Mapping	Advances a record's stage as a visit moves through its phases — finishing a visit moves the job forward on its own.
Cascade Delete	Cleans up related records when a record is deleted, so nothing is left orphaned.
Side Effect	Runs a follow-on effect on a status change — send a notification, flag a record, or pre-fill a field from a related record.

These are configured per record type, as part of its workflow. The ones behind your default Job, Visit, Estimate, and Invoice flows ship ready to go — you don't set them up. An administrator can add new rules to any record type, core or custom.

When a rule runs

Every rule is tied to a moment in a record's life. You choose which one, so the rule fires at exactly the right time.

Trigger	When it fires
Before Create	As a new record is being created — used to validate before anything is saved.
Before Update	As a record is being saved — used to validate a change.
After Create	Just after a record is created — used to spin up related records or run a follow-up.
On Status Change	When a record moves from one stage to another — the trigger behind most automations.

Validation rules

A Validation Rule is how you keep data clean at the source. It checks one or more fields before a record is saved, and blocks the save if something doesn't pass.

You can combine several checks on the same record, and choose whether each runs as the record is first created, every time it's updated, or both.

Check	What it enforces
Required	The field must be filled.
Minimum / Maximum value	A number or currency value must fall within a range.
Minimum / Maximum length	Text must be at least, or at most, a certain length.
Allowed values	The value must be one from a set list.
Format	The value must look like an email, a phone number, or a web address.

A simple Required toggle also lives right on a field. Reach for a Validation Rule when you need more than that — a value range, a length limit, an allowed list, or a check that only runs on certain saves.

Automations in action

The diagram below follows a single piece of work and shows where rules fire. The green steps are the ones FieldCamp performs on its own — no one clicks a button to make them happen.

Read it as a chain: approving a job creates the first visit; finishing every visit completes the job; the completed job becomes an invoice; paying that invoice in full marks it Paid, which in turn marks the job Paid.

Each link is a rule, so the work moves forward while your team stays in the field.

Examples

These are real rules that ship on the core FieldCamp records. They run by default, and you can see their effect on any account.

Child Creation — a job creates its first visit

A Job is the work to be done; a Visit is a single trip to the site.

The moment a job is approved, FieldCamp creates the visits that carry it out, shaped by the job type — a one-off job gets a single visit, a multi-day job gets one visit per day, and a recurring job gets visits from its repeat pattern.

Your team never starts field work from an empty schedule.

Status Propagation — finished visits complete the job

A Job is carried out as one or more Visits. As soon as the first visit is on the way, has arrived, or is underway, FieldCamp moves the job to In Progress.

When the last visit reaches Completed, the job rolls up to Completed on its own — the parent keeps pace with the field without a dispatcher updating it.

Conversion Action — an approved estimate becomes a job

An Estimate is a quote; a Job is the scheduled work. Once an estimate is sent and accepted, FieldCamp converts it into a job, carrying the customer, line items, and totals across.

The same kind of conversion turns a request into an estimate, a job, or an invoice — so an inquiry becomes paid work without anyone retyping the details.

Side Effect — a paid invoice marks the job Paid

An Invoice bills a Job. As payments land, the invoice updates itself — partial when something is paid, Paid when the balance reaches zero, Overdue when its due date passes.

When an invoice created from a job reaches Paid, FieldCamp marks that job Paid in return, closing the loop on the work.

Beyond the basics

A few rules go further than the everyday flow, for businesses that need them.

Scheduled transition

A time-based move — for example, automatically closing a record after a set number of idle days, so nothing lingers in a stage forever.

Auto-default from a relation

Pre-fill a field from a related record, so a new record arrives already populated with details from its parent or a linked record.

Threshold alerts

Flag a record when a number crosses a line you set — useful for catching waste, overages, or anything that should never pass a limit unnoticed.

Because most rules ride on the stages, changing a stage is all it takes to trigger them. Move a job to Completed by hand and the same downstream steps run as if every visit had finished on its own.

Make it your own

Rules ride on top of your stages and fields, so they go hand in hand with the rest of the data model. Rename or reorder a stage and the rules tied to it follow along; add a custom object and you can give it its own rules.

FieldCamp works for any size — single-truck to multi-location franchise, residential or commercial — and the same rules run the same way everywhere, whether you use the defaults as-is or build your own.

Stages & workflows

The stages a rule watches for. Rename, reorder, add, or remove the stages a record moves through.

Objects & fields

Add your own record types and fields. A new object can carry its own stages and its own rules.

Jobs

See the default job workflow, including the rules that create visits and roll the job to Completed and Paid.

Visits

The trips to the site that drive a job's status. Finishing every visit completes the job.