Forms

Forms are how the field talks to the office: photos, hours, materials, checklists, signatures, all captured on a phone at the job site, with or without signal.

Building a form

Forms → New form opens the builder: drag fields onto the canvas, set their rules, save as a draft or publish. Crews only ever see published forms.

Field types cover what field capture actually needs: short and long text, numbers, dates, single- and multi-select, photos (compressed for work shots, original quality for receipts, with annotation and captions), signatures, repeating groups (hours per employee, one row per material), lookups bound to live records (pick the customer, the property, the employee), and reference links to documents.

Fields can show, hide, or become required based on other answers. "Suite #" only appears when the location is a suite.

Versions

Publishing a change bumps the form's version. Past submissions keep the version they were filled under, so a submission from March still renders against March's form, even if the form has changed twice since.

Stage workflows

A form can move through stages (capture, then review, then final approval) instead of being submitted in one go. Configure this in the Stage workflow panel under the builder.

Per stage you decide:

• who can act: any of the app roles (field, lead, ops, admin), or anyone
• which actions are offered: submit, approve, send back, reject
• which signature gates it: the stage can't advance until that signature field is signed
• what happens when it advances: an ordered list of effects:
  • send to someone: route the next stage to an email address (optionally as a guest link that needs no login), an app user, or everyone with a role. Values can use tokens. {employeeEmail} resolves from the submission itself, which is how a write-up routes to the specific employee it's about
  • email a heads-up to someone who isn't acting, just informed
  • fire a webhook

Fields belong to stages: a field is editable at its own stage, read-only at later ones, hidden at earlier ones. A final-review stage can be given edit access to everything.

The Work Order Submission is the in-house example: crew captures and signs, ops reviews and adjusts hours, accounting takes a final pass.

Filling in the field

Crews fill forms from My Work on their phone. Offline is the normal case, not an error: submissions queue on the device and sync when signal returns, and the fill screen shows how many are still pending.

Where submissions go

A submission is not a dead document. Three things read it:

• Work orders: a form bound to a work-order type is dispatched with the work order, and the submission attaches back to it. Photos are extracted and filed automatically.
• Timesheets: hour entries on payroll-relevant forms become time entries. See Timesheets.
• Webhooks: each form can have its own webhooks (configured in the builder), and org-level subscribers hear about every submission.

The submissions list shows who submitted, when, and for which project; multi-stage submissions show where in the workflow they are.

Retiring a form

Two levels, both on the forms list:

• Unpublish puts it back to draft. Crews stop seeing it, history untouched. Publishing again later is fine.
• Retire moves it to the trash. Its submissions remain readable; the form just can't be filled anymore.

There is deliberately no hard delete. A form with submissions behind it is a record, not a file.