Pipeline Stages & Configuration | FieldCamp

Pipeline stages and configuration in FieldCamp controls the entire shape of your request pipeline — which stages exist, which stage-to-stage moves are allowed, what must be captured before a transition fires, and what side effects run automatically when a record changes stage. This guide expands the Transitions tab and the Rules tab so you can move beyond the default flow and bend the request pipeline to match how your business actually closes work.

Accessing Pipeline Configuration

Go to Settings > Pipeline Configuration. Only Admin and Superadmin roles can access this page. See Roles and Permissions for the full permission matrix.

You will see a list of all objects grouped into two sections:

• System Objects — Jobs, Visits, Clients, Requests, Estimates, Invoices, Products/Services
• Custom Objects — Any custom objects you have created with pipelines enabled

Each row shows the object name, description, and the number of stages and transitions configured. Click Requests to open the request pipeline settings.

AI-First: Ask About Pipeline Config

Open the Command Centre and ask:

• "What stages does the request pipeline have?"
• "How many requests are in each stage?"
• "Show me the pipeline configuration"

Default Request Stages

FieldCamp ships with 12 request stages organised across three tab groups — Requests, Pipeline, and Archived:

New Request is the initial stage. Converted, the four archived stages, all act as final stages. Stage values are the slugs the system uses internally — labels are what your team sees on the kanban and in lists.

Managing Stages

Viewing Stages

Open the Stages tab to see all configured stages. Each row has:

Creating Custom Stages

Reordering Stages

Use the up/down arrow buttons next to each stage to change the display order. The order also controls the column order on the kanban view.

Deleting Stages

Click the trash icon next to any custom stage to remove it. System stages cannot be deleted — the trash icon is hidden for those rows.

Managing Transitions

The Transitions tab controls which stage-to-stage moves are allowed. Each row represents one allowed move and is defined by:

Click Add Transition to open the editor, then choose From, To, a button label, and optionally toggle Conversion. FieldCamp blocks duplicate transitions — the same (from, to) pair cannot be added twice.

Wildcard "Any" transitions

Setting From stage to * (Any) makes the transition available from every stage in the pipeline. Use this for housekeeping moves like "Cancel" or "Mark Duplicate" that should always be available without listing every starting stage individually.

Default request transitions

Out of the box, the request pipeline ships with transitions for the full lifecycle, including:

• New Request → Inspection Scheduled ("Schedule Inspection")
• New Request → Quote Created ("Create Quote") — flagged as a conversion
• Inspection Scheduled → Inspection Complete ("Complete Inspection")
• Inspection Complete → Quote Sent ("Send Quote")
• Quote Sent → Converted ("Convert")
• Quote Sent → Lost - Rejected ("Rejected")
• Reopen paths from terminal stages back to New Request

You can keep these as-is, edit their button labels for clarity, or delete the ones that do not match your sales motion. For the full conversion mechanics see Converting Requests.

Required capabilities (gating a transition)

Expand any transition row and you will see a Capability Picker with two sections — Required before transition and Actions on transition. Each capability is a built-in check such as signature, photo, job form, job log, notes, voice notes, or confirmation.

When a capability is enabled on a transition, FieldCamp shows the user a banner on the record detail page calling out what is missing (e.g. "Signature required before closing"). The transition button only succeeds once every required capability is satisfied.

If a capability is greyed out as unavailable, the picker shows an inline link to enable it in Apps & Integrations so admins can wire it up without leaving the page.

Stage Rules and Required Fields

Required fields are enforced through Validation rules rather than on the stage itself. Combine them with transitions for a "must be filled before this stage" effect.

1. Open the Rules tab and add a Validation Rule.
2. Pick the Before Create or Before Update trigger (or both).
3. Add one or more constraints — required, minLength, maxLength, min, max, enum (allowed values), format (email / phone / URL), or pattern (regex) — and set a custom error message.

When a save would violate any rule the request is blocked and the error message is returned to the form. The default request pipeline already enforces that clientId is required on every create and update.

Automation Rules

The Rules tab is where you set up automation that runs around the request lifecycle. FieldCamp's rule engine supports the following rule types:

Status Propagation

Automatically computes a parent's stage from its children. Use this when a request should advance based on what is happening on its visits — for example, when ANY child visit reaches completed, move the parent request to inspection_complete. Choose ANY child matches or ALL children match as the condition type.

Child Creation

Creates child records when a parent reaches a stage. Three generator types are available:

• Single — creates one child record (e.g. one visit per scheduled request)
• Date Range — creates one record per entry in a parent array field (e.g. multi-day jobs)
• Recurrence — creates records on a repeating schedule

Each rule can specify field mappings and default values for the new child.

Conversion Actions

Conversion actions turn a request into a different object — an estimate, an invoice, or a job. The defaults include:

• Convert to Estimate — available from new_request, unscheduled, inspection_scheduled, inspection_complete, quote_created, and duplicate. Sets the request stage to quote_created and tracks the new estimate ID.
• Convert to Invoice — available from new_request, unscheduled, inspection_complete, quote_created, quote_sent, and duplicate. Sets the stage to converted.
• Convert to Job — available from most working stages. Copies the client, address, line items, taxes, and totals, and sets the stage to converted.

See Converting Requests for what data carries over and what happens on the estimate, job, or invoice side after a request converts.

Cascade Delete

Defines what happens to related records when a request is deleted:

• Hard delete — permanently removes related records (line items, taxes)
• Soft delete — marks related records as deleted but keeps them recoverable
• Archive First — moves records to an archive collection before deletion
• Force Required — the delete must be confirmed with a force flag, blocking accidental loss

The default request cascade soft-deletes the request itself and hard-deletes its line items, item taxes, and request taxes.

Side Effects

Side effects fire on stage transitions. They are configured with Trigger on transition to so they only run when the request reaches a specific stage. Supported effects include:

• Update Children — update fields on related child records (e.g. cancel open visits when a request is cancelled)
• Workflow Event — emit a workflow event so a workflow can pick it up and run any sequence you have built
• Recalculate — refresh derived data on the record
• Integration — trigger a sync with a connected integration

FieldCamp also automatically emits a stage_changed event for every transition and a record_created event after creation, so workflows can listen even without an explicit side effect rule.

Auto-Calculation

Sets a field value automatically based on conditions evaluated against child records. Choose a source field on the parent, a child object, a child field, an operator (in, equals, not_in), the match values, and the result value.

Visit Phase Mapping

When a visit phase reaches a chosen status, the parent's pipeline stage advances automatically. Useful for "when the inspection visit completes, move the request to Inspection Complete" type behaviour without writing a Status Propagation rule.

Tying Transitions to Workflow Automation

Every transition that fires emits a stage_changed workflow event that includes objectSlug, recordId, fromValue, toValue, and the full record. That means any workflow you build can listen on stage changes and take it from there — sending an email, creating a task, calling an integration, or updating another record.

Combined with Side Effects, this gives you two layers of automation:

1. Pipeline rules — tight, deterministic actions that always run alongside the transition (e.g. "always cancel open visits when a request is cancelled").
2. Workflows — flexible, multi-step branches you author in the workflow builder that react to those same stage changes.

You can also pre-build common automations from the Workflow Templates library.

Table View and Graph View

At the top of the Pipeline Configuration page, switch between:

• Table view (default) — lists all objects with their stage and transition counts
• Graph view — a visual data model diagram of all objects and their relationships (One-to-Many, Many-to-One, Many-to-Many, Action)

The graph view is handy for seeing how a converted request flows downstream into estimates, jobs, visits, and invoices.

Saving Changes

When you make changes, an unsaved-changes indicator appears in the header. Click Save to commit all stage, transition, field, and rule edits at once. Validation runs on save — if anything is invalid you will see an error toast and the save is rolled back.

Troubleshooting

A transition button does not appear for one of my users

Check the Required Capabilities on the transition. If the capability is unavailable (e.g. the integration powering it is off), the button still shows but the banner asks the user to capture the missing capability before firing. If the user is on a role that cannot see the action at all, review their permissions in Roles and Permissions.

A save is blocked with a validation error

Open the Rules tab and look for a Validation Rule with the beforeCreate or beforeUpdate trigger that references the failing field. Either fill the field on the record, or relax the rule (e.g. remove required).

My request is not moving forward when visits complete

You need a Status Propagation or Visit Phase Mapping rule. Add one that listens on the child visit object's status and sets the parent's stage to the desired value when ANY (or ALL) visits reach the target status.

A new stage I added does not show up on the kanban

Save the pipeline first — unsaved stages do not appear on the kanban. Then make sure the stage's tab group is set so it lands in the right column group on the sales pipeline board.

FAQs

Can I delete a system stage?

No. System stages are built into FieldCamp and cannot be removed. You can delete custom stages, and only when no records are sitting in them.

What is the difference between hard delete and soft delete in cascade rules?

Hard delete removes related records permanently. Soft delete marks them deleted but keeps them in the database for recovery and auditing. Each cascade target can choose its own strategy.

Who can access Pipeline Configuration?

Admin and Superadmin roles. Dispatchers, field technicians, and other roles cannot view or modify pipeline settings. See Roles and Permissions.

How do I auto-advance a request when an inspection visit is complete?

Use a Status Propagation rule on the request — child object visit, child field status, operator in, value completed, condition type ANY, result stage inspection_complete. Or use a Visit Phase Mapping rule, which is the lighter-weight equivalent.

Can a transition trigger a workflow automation?

Yes. Every transition emits a stage_changed workflow event automatically — listen for it in the workflow builder. For deterministic in-engine effects, add a Side Effect rule with the Workflow Event effect.

Related Articles

• Requests Overview — what requests are and the full lifecycle
• Creating & Tracking Requests — capture incoming inquiries
• Sales Pipeline Kanban — the visual pipeline board
• Converting Requests — turn requests into jobs, estimates, or invoices
• Request Detail Page — manage a single request end-to-end
• Roles and Permissions — who can configure pipelines
• Building Workflows — automate actions beyond pipeline rules
• Workflows Overview — how workflows listen to stage events
• Workflow Templates — pre-built automations to start from
• Custom Objects, Fields, and Pipelines — pipelines for your own data types
• Command Centre — ask the AI about your pipeline
• Apps & Integrations — enable capabilities used by transitions
• Creating Estimates — what happens after a request converts to a quote