FieldCampStages & Workflows — Customize Your Process | FieldCamp
Every FieldCamp record moves through stages you define. Set up workflows, control which moves are allowed, and require information before a stage change.
Every record in FieldCamp moves through a series of stages, and you control what those stages are.
A Job runs from Draft to Paid, a Request runs from New Request to Converted, an Invoice runs from Unpaid to Paid — and each path is a workflow you can rename, reorder, extend, or reshape to match how your business actually works.
Stages are the statuses a record can hold; the moves between them are the steps of your process. This page explains what a stage is, how records move between stages, how to require information before a move, and the common shapes a workflow can take.
Every record type ships with a sensible default workflow on day one, so you can change as little or as much as you need.
Stages
A stage is a status a record can hold at a point in its life — Draft, Scheduled, In Progress, Completed.
Each stage has a name you choose and a color for its status pill, and the stages sit in an order that reads as the natural progression of the work.
On a Job, that order is Draft, Scheduled, In Progress, On Hold, Completed, Invoiced, Paid, Cancelled, Closed.
Two kinds of stage anchor every workflow:
- A starting stage. One stage is marked as where new records begin. A new Job opens in Draft; a new Request opens in New Request; a new Invoice opens in Unpaid. When a record is created, it lands on the starting stage automatically.
- Final stages. One or more stages mark the end of the line. A Job ends at Closed or Cancelled; a Request ends at Converted, Lost, Cancelled, or Duplicate. A record that reaches a final stage has finished its journey, and the actions available on it narrow accordingly.
The stages in between are the working states the record passes through. You decide how many there are, what they are called, and the order they appear in.
A few stages are managed by FieldCamp and run behind the scenes — for example, the queued and suggested states the AI dispatcher uses while it works out a schedule.
You can build your own workflow freely around the stages you own; the platform-managed ones stay out of your way.
Transitions and guardrails
A workflow is more than a list of stages — it is the set of allowed moves between them.
Each move from one stage to another carries the label your team sees on the button that performs it: Schedule, Start Work, Complete, Put On Hold, Cancel. Defining which moves are allowed is what turns a pile of statuses into a process.
A Job can go from Scheduled to In Progress with Start Work, but it cannot jump straight from Draft to Paid, because no such move exists in the workflow.
Allowing a move is one half of the control. The other half is requiring something before the move is permitted. You can attach a requirement to a move so a record cannot advance until it's met:
- A customer signature — captured before a visit or job is finished.
- Photos — a set number, before the move goes through.
- Notes — written before advancing.
- A completed job form or job log — an inspection filled in, or a time-and-cost entry made.
- A confirmation prompt — a check on an important or hard-to-reverse move before it goes through.
For teams that need them, a move can also require a QR-code scan, manager approval, or an SLA check. Some of these depend on the matching add-on being turned on.
These requirements are what keep your data clean without anyone policing it. Each one travels with the move, so the rule is enforced the same way every time, whether the move is made from a desk or from a phone in the field.
Requirements are toggles you can turn on or off per move. If your residential crews need a signature to finish a visit but your commercial crews do not, you can require the signature on the move that matters and leave the others open.
Example: a job workflow
Here is a streamlined job workflow — the spine of the default Job process, showing the named action that performs each move.
A new job starts in Draft, is approved and scheduled for work, runs through the field, and finishes as Completed, with branches to put it On Hold or Cancel it along the way.
The move from In Progress to Completed is a natural place for a requirement: ask for notes, or a captured customer signature, before the Complete action is allowed.
The record cannot reach Completed until that information is in place, so every finished job carries proof the work was done.
Design your own
Most real workflows are a variation on three shapes. Start from the one that fits your process and adjust the stages and guardrails from there.
Linear flow
A straight line from start to finish, with each stage leading to the next: Draft → Approved → In Progress → Completed. This is the simplest shape and the right starting point for a process where work always moves forward through the same steps.
Add a guardrail on the final move so nothing reaches Completed without the details you need.
Branching flow
A main path with side routes for the real-world detours. A job in progress can move forward to Completed, or step aside to On Hold and later Resume back into the flow — and Cancel is available from several stages for work that falls through.
Branching flows handle pauses, cancellations, and reopens without forcing every record down one rigid track.
Approval flow
A path with a checkpoint where work is approved or sent back.
A record moves into a pending-approval stage, then either advances when approved or returns to be revised when rejected: Draft → Pending Approval → Approved → In Progress, with a Rejected → Draft loop for revisions.
This is the shape to use when someone has to sign off before work proceeds — a quote, a permit, or a job above a certain value.
You can mix these shapes freely. A workflow can run mostly linear, branch out for holds and cancellations, and still include an approval checkpoint partway through.
The same approach works for any record type — Jobs, Requests, Invoices, or a custom object you create — so the process you design lives consistently across your business.
Make it your own
Stages and workflows are one layer of FieldCamp's customization. They work the same whether you run a single truck or a multi-location franchise, residential or commercial — the same stage names, moves, and guardrails apply at every site.
Pair workflows with the rest of the data model to shape FieldCamp around your process.
Make a stage change trigger the next thing automatically — create a visit, convert a record, send a notification, or move a related record forward.
Add your own record types and fields, then give each one its own stages and workflow.
See a real workflow in action — how a request moves from new to quoted to converted into a job, estimate, or invoice.
See the full default Job workflow, from Draft through Scheduled, In Progress, Completed, Invoiced, and Paid.
See also
More in the FieldCamp data model.
How the core records connect, and how to make them your own.
Plain-language definitions of every term.
Related guides
Hands-on, step-by-step guides from the rest of the FieldCamp documentation.
Record Layouts — Building Blocks | FieldCamp
Every FieldCamp record page is built from configurable building blocks you can reorder, group into tabs, and tailor by record type — with role-based access built in. Customize layouts.
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.